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Dear Reader: 
What is a book? Is it perpetually fated to be inky words on a paper page? Or can a book 
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simply be something that inspires—feeding your head with ideas and creativity regardless 
of the medium? The latter, | believe. That's why I'm always pushing our books to a higher 
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plane; using new technology to reinvent the medium. 
I wrote my frst book in 1973, Projects in Sights, Sounas, and Sensations. | like to think of 
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it as our first multimedia book. In the years since then, I've learned that people want to 
experience information, not just passively absorb it—they want interactive MTV in a book. 
With this in mind, [ started my own publishing company and published Master Ca 
book/disk package thar curned the PC into a C language inseructor. Then we branched out 
to computer graphics with Jaca! Creations, which included a color poster, 3-D glasses, 
and a totally rad fractal generator, Ever since, we've included disks and other goodies with 
most of our books. Virtwa! Meaty Creations is bundled with 3-D Fresnel viewing goggles 
and Walkthroughs ana Filybys CD comes with a multimedia CD-ROM, We've made 
complex multimedia accessible for any PC user with Ray racing Creations, Multimedia 
Creations, Making Movies on Your PC, Image Lab, and three books on Fractals. 

The Waite Group continues to publish innovative multimedia books on cutting-edge 
topics, and of course the programming books that make up our heritage, Being a 
programmer myself, | appreciate clear guidance through a tricky VS, so our books come 
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patience, run a simulation to visualize the topic, play a game that shows you different 
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In the meantime, they've wired the White House for hi-tech; the information super 
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information are becoming inseparable. To travel in this Digital Age vou'll need 
suidebooks. The Waite Group offers such guidance for the most important software— 
your mind, 

We hope you enjoy this book. For a color catalog, just fill out and send in the Reader 
Report Card at the back of the book. 


Mitchell Waite 
Publisher 





Introduction 





This book is a companion volume of sorts to my earlier Waite Group book, 
Flights of Fantasy. Where Flights of Fantasy concerned three-dimensional fight 
simulator programming, Gardens of /magination tackles a subject that's a bit more 
down CO earth — SOMCctlmes even under the earth. 

Throughout this book, | refer to the type of gare that its about as “three- 
dimensional maze games, despite the fact thar these games really have no 
collective name. The maze game encompasses a number of traditional computer 
game genres, including CRPGs, arcade games, and adventure games. What these 
games have in common is that each uses three-dimensional graphic techniques to 
depict the interior of a maze, which may in turn represent the interior of a 
dungeon, a spaceship, a jungle, even a castle occupied by Nazi stormtroopers. If 
youve played Ultima Underworld from Origin Systems, Wolfenstein 3D from 
Apogee Software, Doom from ID Software, Arena from Bethesda Softworks, or 
any of a host of other maze games to appear over the last few years, you should 
immediately recognize the type of game that I'm talking about. If not, you have a 
treat in store. 

As in Flights of Fantasy, ve stacked this book from cover to cover with 
computer code demonstrating how to duplicate the effects in these games, 
including a working computer game developed in the last chapter. This code ts 
intended nor as a library of routines for the reader to plug into his or her 
programs (though its possible to use the code as such), bur as a series of examples 
to point the reader in the right direction and inspire him or her to produce code 
that lies even closer to the bleeding edge. Until recently, there was surprisingly 
little information available in print for programmers interested in writing 
commercial quality computer games. | hope that this book and Flrehts of Fantasy 
have helped to alleviate that situation at least a little. 
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This book includes a disk containing all the code that appears in these pages. 
Its probable that changes will be made to that code between the typesetting of 
the book and the mastering of the disk. If so, these changes will be documented 
in a file on the disk entitled README.TXT, If you have any problem getting 
this code to do what you want it to, or just want co tell me what you think of the 
book, you can contact me on CompuServe at ID 76711,301. Or log onto the 
Game Design Section of the CompuServe Gamers Forum (GO GAMERS), 
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Installation 





Gardens of Imagination includes a disk that contains the source code, utilities, 
and maze discussed in the book. The files are in a compressed format, and should 
be installed on a hard drive betore you use them: you ll need a minimum of 3MB 


of free hard disk space. 
To install the files, follow these steps: 


|. Change to root directory of the hard drive on which you wish to install the 
files. If the hard drive you wish to install the files on is the C: drive, at the DOS 
prompt you would cype: 


c: ENTER 
cd\ (ENTER 


lf the hard drive is not C:, type the appropriate letter instead. 

2. Create a directory for the files on the hard drive called GARDENS by typing: 
md gardens ENTEA 

You may use a directory name other than gardens, if you so preter. 

3. Change into the newly created directory. lo change into the directory 
GARDENS, type: 

cd gardens ENTER 

4. Insert the Gardens of [Imagination disk into your 3.9-inch floppy drive. If that 
floppy drive is the A: drive, hype: 

a: \gardens <-d 

If its the B: drive, type 

b:\gardens <d 

Be sure to include the -d switch after gardens, so that the subdirectories and their 
hles extract properly. Depending on the speed of your PC, the decompression 
and transfer of the Gardens of Imagination files may take a couple of minutes. 
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Ou are trapped in a vast maze. 
Its nor thar youre a pessimistic kind of person — you always 
like to look on the bright side of things, even when you need a 
Hashlight to find it — burt things are getting pretty grim. You 
~eewweiiieees’ = ran out of food half an hour ago. You barely have enough magic 
left to heal a wart. Your hit points are so low that you can count them on your 
fingers and toes and still have enough digits left over to play “This Little Piggy.” 

To make Matters worse, there's something Out there in the darkness, 
something thats hungry and in a real bad mood. You hold up your flickering 
torch and try to get a look at it, but the fame is so low that you can barely see 
ten feet in front of you. OF course, that's probably for the best. If you can't see 
whats our there, maybe it cant see you either. 

Some fun, huh? 

Things could be worse. You had the foresight to save your game back in the 
last town, so even if that thing you hear licking irs lips out there in the shadows 





decides to have you for dinner, you'll only lose 30 minutes of dungeon crawling. 
And maybe next time youd better crawl in a different dungeon, until you have as 
much experience as some of those hypermuscular barbarians youve seen hanging 
around the adventurers guild in recent weeks. 

This dungeon is way too tough! 
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The Once-and-Future Maze Game 


Fighting slavering monsters in a dark, maze-like dungeon may not be anybody's 
idea of fun, but when the dungeon is on the video display of a computer and the 
monsters are only bits and bytes shuttling through the silicon circuitry of a 
microprocessor, it can be a blast. The sort of computer role-playing game (or 
CRPG) that we've been describing in the last few paragraphs belongs to a larger 
genre of computer game, which were going to refer to in this book as the maze 
game. CRPGs, however, are only one type of maze game. Other maze cAMes 
would be better described as arcade games. And still others fall into the genre 
known cS adventure PamMes.. All of these Paes, though, have One thing i if] 
common: [hey drop the player into the middle of a maze-like environment, and 
they depict that environment on the video display of the computer using 3D 
eraphics. At a time when the buzzword ‘virtual reality” is on every game 
programmers lips, these games pur the player right in the thick of a virtual world, 

[F You like COMPUTE Panmics, youve probably played More than | few that 
match this description. In this book, however, were going to go beyond telling 
you how to play such games. Were going to tell you how to create them. If 
there's anything more fun than hacking and slashing your way through a virtual 
reality, its creating your own virtual world! 

Maze games are not new. Theyve been around almost as long as there have 
been microcomputers — and maybe a bit longer. The original Crowther and 
Woods advencure eeavic, which first appeared On maintrames and minicomputers 
in the late 1960s, featured a sequence in which the player was trapped in a “maze 
of twisty little passages, all alike,” though the maze was only described in words, 
not illustrated with graphics. 

By the late 1970s, however, crude micromputer maze games had begun to 
appear. Some of these games rendered the interiors of mazes using simple line 
drawings, in which passageways were depicted by parallel lines extending away 
from the viewer toward the vanishing point, like something from the sketchbook 
of a Renaissance artist who had just discovered the laws of perspective, We'll refer 
to this type of depiction as a wireframe maze, by analogy to the wireframe 
graphics used in early microcomputer Hight simulators. As crude as the graphics 
might have been, some of these early maze games were quite entertaining — and 
a couple of them spawned lines of sequels that are still appearing today. 

Perhaps the most successful of these early maze games was Ultima, published 
in 1980 by then teenaged programmer Richard Garriort for the Apple II. 
T hough Mose at the ee TLe took place On a scrolling two-dimensional Map, the 
intrepid player could enter a series of dungeons scattered around the landscape 
and feast his or her eyes on state-of-the-art 1980 wireframe maze graphics. It 
wasn't necessary to enter the dungeons to win the game (though in later Ultima 


CHAPTER ONE Lost in the Maze 














Figure 1-1 A scene from one of the early Wizardry games. The 
graphics may have been simple, but the qames were bia 
COMPpIEX, dnd Quite popular 


games it would be), but they provided an entertaining treat for the player who 
wanted to experience a crude kind of virtual realiry, So successtul was this early 
computer role-playing game that Garriott parlayed its popularity into his own 
game publishing house, Origin Systems, which ts still producing Ultima sequels 
today. Not bad for a game that was originally written in Applesoft BASIC. 

The Wizardry series of games, begun in 1982 by Sir-Tech Software, carried the 
wireframe Maze concept a step farther. The first five Wizardry games took place 
entirely in wireframe mazes, using high resolution color graphics only for the 
monsters that periodically assaulted the players (see Figure 1-1), Like the Ultima 
games, the Wizardry series is still being produced in the 1990s and shows no 
signs of waning in popularity. 

It would be difficult, if not impossible, to catalog all the maze games that 
appeared in the subsequent decade. Many of these games, such as Labyrinth and 
Asylum, were designed for microcomputer systems that have long ago passed on 
to silicon heaven. (That particular pair of games appeared originally on the Radio 
Shack TRS-80 Model I in the early 1980s.) Others, like Slaygon on the Atari ST 
and Commodore Amiga, came and went so quickly thar only rabid aficionados of 
the genre remember them at all. 

Nonetheless, dedicated microcomputer gamers have warm memories of such 
popular maze-style games as Electronic Arts 1986 The Bard's Tale series, which 
updated the Wizardry-type dungeon with detailed color graphics and, eventually, 
cleverly animated monsters, or SSIs “gold box’ series of CRPGs, which debuted 
in the late 1980s with Pool of Radiance and spawned more sequels and quasi- 
sequels than any other game published up until that time (see Figure 1-2). For 
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Figure 1-2 One of several dozen three-dimensional mazes 
from Pool of Radiance, the first of SSIs highly successful series 
oF “gold box" CRRPGS 


microcomputer gamers who owned an ST, an Amiga, or an Apple IGS during 
that same period, perhaps the most fondly remembered of all maze games is 
Dungeon Master (FTL Games), which used bicmap images and digitized sound 
effects to create a dungeon maze so startlingly realistic that players tend to 
remember it not as a game that they once played but as a place they actually 
visited (see Figure 1-3). Eventually, Dungeon Master was translated from the 
Atari, et al., to the IBM PC and its clones, which by the early 1990s had become 
the preeminent platforms for microcomputer games; but by that time it had 
spawned a series of imitations that were nearly as entertaining as the original. 
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Figure 1-3. The most realistic maze game of the 1980s, 
Dungeon Master is regarded by many fans as the best CRPOG 
ever published 
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Figure 1-4 The best of the Dungeon Master clones was Eye oF 


the Beholder, published by SS! and crafted by the programming 
tearm at Westwood Associates 


The best of these Dungeon Master clones was SSI's Eye of the Beholder, from the 
programming team at Westwood Associates (see Figure 1-4). 


Face to Face with (Virtual) Reality 


For all its bone-chilling realism, Dungeon Master turned out to be merely a 
precursor to the super-realistic maze games of the 1990s. Dungeon Master may 
have featured superbly detailed maze graphics, and arguably the best mouse- 
driven interface ever applied to a microcomputer game, but the method used to 
animate the maze bore more than a passing resemblance to that used almost a 
decade earlier by Richard Garriote in the first Ultima, The player moved around 
the dungeon by pressing the arrow keys on the computers keyboard (or clicking 
with the mouse on equivalent screen icons). For every press of a key, the player 
moved a fixed distance forward down a hallway or rotated in place by 90 degrees. 
All movement was in quantum leaps: It was not possible to move a shorter 
distance down the hallway or rotate in place by only 45 degrees. Such coarse 
movement controls were good enough to allow players to suspend disbelief and 
project themselves mentally into the dungeon, but they werent truly realistic. In 
the real world, movement is smooth and fluid, not discontinuous. (Physics fans 
may respond that this argument breaks down when applied to particles the size 
of, say, electrons, but its essentially true for large-scale objects such as human 
beings. } 

By contrast, computer Hight simulators such as Microprose’s F19 Stealth 
Fighter and Spectrum Holobytes Falcon have long shown game players that it 1s 


= 
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possible to create a computer game with three-dimenstonal animation that ts 
smooth and Huid, much more like movement in the real world. Armchair pilots 
Hying the Piper Cherokee Archer in Microsofts Flight Simulator had nearly total 
freedom of movement. Computer-simulated airplanes don't move ahead by 
sudden leaps (except on computers with sluggish CPUs). They slide through 
space in a continuous motion. And when they rotate, they do so by fractions of a 
degree, Of course, this simulated movement takes place high in the sky, with the 
nearest visible objects a safe distance away. Would it be possible to transfer the 
Huid animation of flight simulators to the interior dungeon environments of a 
maze game: 

Yes, it would be. The first major maze game to utilize the techniques of flight 
simulator programming in depicting the dank interior of a dungeon was Ultima 
Underworld, a distant descendant of Richard Garriotts 1980 CRPG. (A much 
earlier Atari 800 game called Way Out, from Sirius Software, also used Hight 
simulator techniques to create a remarkably effective maze environment, but only 
the most fanatic computer gamers — the author of this book, for instance — 
remember that this game existed.) Published in 1992 by Ongin Systems, Ultima 
Underworld allowed the player to craw! through the slimy environs of a vast 
underground complex, all of tc depicted with fight simulator-style animated 
graphics. While screen shots from the game, such as the one in Figure 1-5, may 
not look as realistic as those from Dungeon Master or Eye of the Beholder, the 
smoothness of the animation more than compensated for any shortcomings. The 
Underworld dungeon may not have looked real, but ir fefr real, with the kind of 
pit-ofthe-stomach believabiliry that computer games very rarely achieve. Ultima 
Underworld brought the maze game into the age of virtual reality. 


Pir rr 





Figure 1-5 Ultima Underworld brought the maze game into 
the age of virtual reality 


CHAPTER ONE Lost in the Maze 


A Maze in Wolf's Clothing 


Ultima Underworld may be the most realistic and detailed maze game to come 
down the pike so far, but only a few months after it was released, another maze 
game appeared thar made even seasoned Underworld players shake their heads in 
astonishment. Called Wolfenstein 3D and marketed as shareware by Apogee 
Games, it featured a maze environment that was in some ways less believable, and 
certainly far less detailed, than the one in the Origin game (see Figure 1-6). Bur 
what it lacked In realism, it more than made up for in sheer velocity. Wolf 3D, as 
it ts popularly known, was by all odds the fastest maze game ever published. Like 
Underworld, it allowed the player to move smoothly and fluidly through a maze 
of rooms and passages, but at a far more hectic pace. Wolf 31) was pure action, 
Tossing aside most of the role-playing features of earlier maze games, Wolf 3D 
was a compulsively playable arcade game. 

It was also the first of a new genre of maze game. The programmers at Id 
Software, who had developed Wolf 3D for Apogee, marketed the animation 
engine from that game to other programmers who wanted to produce their own 
Wolf 3D-style games. One of the first of these, Blake Scone: Aliens of Gold 
(written by Jam Software), was released by Apogee in late 1993 (see Figure 1-7). 
In the meantime, the programmers at Id proceeded to develop a more advanced 
version of the Wolf 3D animation engine, with more features than the original. 
This engine became the basis for a game called Doom (see Figure 1-8), published 
in December 1993, which took place in a far more realistic maze environment 
than the one in Wolf 3D. Doom introduced lightsourced 3D graphics and 


heightmapping to the Walt 3D-style maze game. Translated from computerese, 





Figure 1-6 The wildly popular Wolfenstein 3D introduced anew 
type of maze game that combined elements of CRPG and 
arcade game with smooth three-dimensional animation 
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Figure 1-7 Blake Stone: Aliens of Gold uses the animation engine 
developed for Wolfenstein 3D 


that means that the maze in Doom is illuminated by changing and moving light 
sources and that the Hoor rises and falls. Stairs lead from one dungeon level to the 
next. Walls fade in and out of view as they move closer to and farther away from 
the plaver'’s lantern. Lights blink on and off. (Much of this was also true of 
Ultima Underworld, but Wolf 3D used a different — and potentially faster — 
style of animation than Underworld, as we'll see later in this book.) 

Inspired by the success of Wolf 3D, more “smooth-scrolling arcade games” (as 
they are sometimes called) appeared in 1993, including Shadowcaster from 
Origin Systems, which also used the Id animation engine. Bethesda Softworks 


Figure 1-8 Although written by the same programmers who 
produced Wolfenstein 3D, Doom features even more 
sophisticated and innovative maze graphics techniques 
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Figure 1-9 Terminator: Rampage is a maze game based on the 
pooular senes of films 


published a maze game called Terminator: Rampage (based on the popular hlm 
series); in 1993 (see Figure 1-9) and The Elder Scrolls: Arena in early 1994 
(Figure 1-10), Westwood Associates, now with their own label separate from 
SSI, released a Dungeon Master-style CRPG called Lands of Lore in the 
summer of 1993. 

As the mid-1990s neared, it was clear thar the maze game was the hottest 
thing going in the world of computer games. This left a lor of computer game 
programmers scratching their heads and asking the inevitable question: Just 
how do Vou write Ore at these Pamecs, anyway? 
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Figure 1-10 The Elder Scrolls: Arena applies Wolf 30-shyle 
animation techniques to the CRPG game 
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The short answer to that question is that there are several different ways to write 
a maze game, In fact, it could be argued that there are as many different ways of 
writing a maze game as there are programmers writing them. 

However, we can break the vast majority of maze games down into four basic 
types, each of which is programmed in a different manner. In this book, we'll 
refer to those types as wireframe mazes, bitmapped mazes, polygon mazes, and 
ray-cast mazes. (It's also possible to divide maze games into genres such as 
CRPGs and arcade games. In this book, however, we'll be talking mostly about 
the technical details of implementing such games, not the higher-level details of 
game design. [his should not be taken to mean that game design is not 
important, just that it deserves a great deal more space than I would be able to 
give it in this book.) 

Each of the maze games mentioned earlier in this chapter falls into one of 
these four categories: 


| Wireframe mazes: The early Ultima and Wizardry games 


(|| Bitmapped mazes: The Bard's Tale series, Dungeon Master, the $51 "gold box" 
games, Eye of the Beholder, the later Wizardry games, Lands of Lore 


| al Polygon mazes: Ultima Underworld 1 and 2 


=| Ray-cast mazes: Wolfenstein 3D, Doom, Blake Stone: Aliens of Gold 


Although some of these types of maze game may look superficially similar to 
the player, from the programmer's point of view each requires a very different 
approach. 


Wireframe Mazes 

Wireframe mazes are the simplest type of maze to program and require the least 
CPU power and memory resources to animate, which is why this approach was 
used in most of the early microcomputer maze games, All the programmer needs 
in order to create this type of maze tsa fast line-drawing routine and the patience 
to figure out where to put the lines on the display. The programming techniques 
required for creating a wireframe maze are simple and straightforward, and no 
advanced mathematics are required, We'll discuss wireframe maze techniques in 
some detail in the next chapter. 
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Bitmapped Mazes 

Bitmapped mazes arent much more difficult to program than wireframe mazes, 
In fact, it could be argued that theyre a little easier, since no line-drawing routine 
is required. Bitmapped maze graphics are pieced together from predrawn images 
of walls, Hoors, ceilings, and bits of set decoration. The only catch is that a 
competent artist is required to draw these images (though in some instances a 
ray-tracing program will sufhce), Once drawn, getting the images on the video 
display is a piece of cake, relatively speaking. We'll discuss bitmapped mazes in 
more detail in chapter 4. 


Polygon Mazes 


Polygon mazes are the most difficult type to program. The techniques used to 
animate such mazes are essentially the same as those used to animate 
microcomputer Hight simulators, and they require at least a passing knowledge of 
trigonometry and Feomecry on the Part at the PORTA LITLer. The results, however, 
can be worth it. Polygon mazes are potentially more realistic than the mazes 
created using other methods, but they require the programmer to overcome a 
series of difheult technical problems, including hidden surface removal, polygon 
clipping, three-dimensional database design, and texture mapping, Ironically, the 
images in a polygon maze program are often less realistic than those in a 
bitmapped maze game, but the greater realism of continous, flight simulator-style 
movement more than makes up for this lack of realism, We'll talk about polygon 
mazes at some length in chapters 5 and 6, 


Ray-Cast Mazes 


Ray-cast maze techniques are surprisingly easy to master and can produce effects 
almost as vivid and realistic as those found in polygon maze games. Ray-casting 
techniques use simple principles of optics to project a detailed image of the Hoor, 
walls, and ceiling of a maze onto the video display of a computer. These 
techniques resemble an extremely simplified version of the ray-tracing techniques 
that are used to produce highly realistic animated images for movies and TY. 
(Well discuss ray tracing at greater length in chapter 8.) The only drawback of 
ray Casting as a method of drawing mazes is that the ways in which the player ts 
allowed to move through the maze must be limited somewhat and the types of 
objects that the player can encounter must be somewhat reduced relative to a 
polygon maze game. However, in a cleverly designed maze game, most players 
will never notice these limitations. Player movement in a ray-cast maze game can 
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be every bit as Huid and realistic as in a polygon maze game, and in many cases 
the animation is even smoother. This combination of programmer ease and high- 
velocity animation makes ray casting the ideal method for creating arcade-style 
maze games on current generation microcomputers. For that reason, we'll spend 
the last five chapters of this book discussing ray-casting techniques and 
developing a ray-casting animation engine that can be used to produce both 
arcade-style maze games and CRPGs. Well even develop a game that uses this 
engine. 


Animation Programming 


In the chapters that follow, we'll recapitulate the evolution of the maze game, 
exploring the whole gamut of techniques used to render more and more realistic 
mazes on the microcomputer video display, Before we can talk about maze game 
programming, however, we ll need to Sel el few words about COMPUter graphics 
and animation in general. In the next chapter, we'll discuss the basics of 
producing images on the video display of an [BM-compatible microcomputer — 
then we'll use those techniques to create the rudiments of a wireframe maze 
game, similar in visual spirit to the early Wizardry games. 
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rogramming the video display of a microcomputer isnt difheult. 
Most computer programming languages come with either a 
built-in set of commands or a standard library of functions for 
putting information on the display. The problem ts, these 





commands and functions arent necessarily up to the demands 
that a game programmer is likely to place on them. There are libraries of 
functions available that have been optimized for game programming needs, and 
many game programmers find these libraries indispensable, but they will cost you 
money abave and beyond the small fortune that youve already laid LIE To buy 
your compiler or interpreter. 

In this book well develop our own set of graphics functions in Borland C++ 
and assembly language for outputting graphics to the video display of an IBM- 
compatible microcomputer. The Borland compiler comes with a graphics library 
called the BGI (for Borland Graphics Interface), bur the functions included in it 
arent fast enough or versatile enough to handle the tasks that we're going to 
throw at them, If you have a favorite library of graphics functions that youd 
prefer TO sé, feel free to substituce them Ww ‘here we in Your own code. 
However, writing graphics code from scratch isnt a lot more difficult than 
learning to use a prewritten library of functions — and the graphics code that 
you write yourself is guaranteed to do exactly what you want it to do. 

After you've finished debugging it, anyway. 
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Video Memory: A Brief Tour 


The major concept that you need to understand in order to program graphics on 
an [BM-compatible microcomputer (or just about any other type of micro- 
computer, for that matter) is the concept of video memory. Inside your 
microcomputer, usually in one of the slots attached to the motherboard, is a set 
of electronic circuits that store an encoded version of the image currently on the 
video display. Change the contents of these circuits and you change the image. 
Programming graphics ts as simple — and as complicated — as that. 

Up until now, you may not have delved into the esoteric rules of programming 
a computer on the level of bits and bytes, But its time to lose your innocence. 
Programming your computers memory directly — especially the video memory 
— may sound intimidating, but it’s simple once you learn the rules, 


Offsets and Addresses 


Every type of information that's stored inside your computer — programs and 
databases, graphics and musical scores — is stored in memory. Yet memory is 
nothing more than a series of electronic circuits, each of which can store an 
electrical representation of a binary number — that is, a number made up of the 
digits 0 and 1. We dont have to worry precisely how these numbers are 
represented electrically or even how the binary numbering system works, because 
most programming languages will do the work of translating other forms of 
information into the internal form required by the computer and not bother us 
with the details. However, it helps to understand the essential layout of the 
computers memory if youre going to put images on the screen. 

Each memory circuit can hold a number in the range 0 to 255. (I’m 
representing these numbers using the decimal numbering system, because thats 
the only system that all readers of this book are guaranteed to be familiar with, 
but the memory circuits store them in binary.) There are commands in the C++ 
language, as in most other programming languages, that will place a number in a 
memory circuit or retrieve a number that’s already stored in a circuit. 

Because its importante that data be retrieved from the same memory locations 
in which it has been stored, each location has an identifying number, called an 
address, that can be used to distinguish it from other locations. Its traditional to 
write these addresses using the hexadecimal numbering system. Hexadecimal has 
strong mathematical ties to binary, which makes it easy to translate from one 
system to the other; however, it takes fewer digits to represent a number in 
hexadecimal than in binary, making it by far the less unwieldy of the two 
systems. Hexadecimal numbers use 16 different digits, che numerals 0 through 9 
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plus the letters A through F. The number 65535 in hexadecimal, for instance, is 
FFFE In C++ or C, this would be represented as Oxf, with the “Ox” identifying 
the number as hexadecimal. 

The addresses used to identify memory locations in [BM-compatible 
microcomputers are made up of two parts: a segment and an offset. The reasons 
for this are complex and have to do with the nature of the IBM hardware; were 
noc going TO gO Into what they ATC. Each of these numbers, the scEMene and the 
offset, can fall anywhere in the range 0000 to fff hexadecimal — that’s 0 to 
65535 in decimal. The address is written by separating the segment and offset 
with a colon, like this: 1234:5678. Such a segment-oftser patr can also be 
translated into a /inear address by multiplying the segment by 16 and adding it to 
the offset, though you'll rarely, if ever, need to do this. It's important to bear in 
mind, though, that nwo segment-offset pairs that translate into the same linear 
address represent the same location in the computers memory, even though the 
segment and offset numbers may be different. Thus 0000:0010 and 0001:0000 
represent the sdalTie Memory location, because they barh translate To the linear 


address 00010 hexadecimal for 16, in decimal). 


Manipulating Memory with Pointers 


A C++ programmer can use several different methods to put a numeric value into 
a memory location, Every time the value of a variable is changed, for instance, 
Oe OF TMOTe numbers AT placed in Memory locations thar have been assigned td 
that variable by the C++ compiler, To interact with video memory, however, the 
programmer needs to be able to change the value of specific memory locations 
rather than locations chosen arbitrarily by the compiler. 

The most direct way to change the value of a specific memory location is to 
use a C++ pointer. A pointer is a variable thar represents the address of a location 
in the computers memory. In most versions of C++ written for IBM-compatible 
microcomputers, pointers come in two varieties: near pointers and far pointers. 
The primary difference berween the two is that the programmer can control 
precisely which memory location a far pointer represents, but can only control 
the offset of the Mmecmory location represented by a Tear pointer. The SCO ment 
portion of the address pointed to by a near pointer is determined by the 
operating system at the time the program is loaded. Since we need to control 
both the segment and offset portions of the address in order to interact properly 
with video memory, we ll be using far pointers exclusively in this book. 

When declaring a pointer, the programmer must tell the compiler what sort of 
values it will be pointing to in the computers memory — int, char, float, and so 
on. In programming video memory, well need to point to byte-sized values, so 
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we ll LISe pointers To values of type char. A far pOLNtEr tO values of ype char 1s 


declared like this: 
char far *charpointer;: 


This declares a far pointer called charpomnter, which points to values of type char, 
To set charpointer equal to a specific memory address, we use the MK_FP macro, 
which is defined in the Borland header file DOS.H. In order to use it, you'll need 
ro include DOS.H at the top of your program file. 

The MK_FP macro — the name stands for “make far pointer” — is used like 
this: 


charpointer = (char far *) MK_FP(Ox/456, Ox0890): 


This assigns the address 7456:0890 to the pointer charpointer. The typecast in 
parentheses in front of the MK_FP macro converts the pointer, which is a far 
pointer to type vod, into a far pointer to type char, 

After all this work, we're finally ready to place a value in the memory location 
pointed to by the pointer. To do so we must dereference the pointer, which is 
done using the * or dereferencing operator, like this: 


*charpointer = 179; 


This assigns a value of 179 to the memory location 7456:0890, assuming that 
the value of charpointer has not been changed since the previous assignment 
statement. To retrieve this value, we can put the dereferenced pointer on the 
other side of the assignment operator: 


char thisvar = *charpointer; 


This assigns the value stored at the address pointed to by charpetnter to the char 
variable thisvar, (You ‘ll notice that we ¥e declared the char variable thisvar | In the 
assignment Statement itself. This 1 iS allowed 1 in ‘ers aL the time of a variable's first 
use, though it's important to note that the variable will only be valid in the block 
where it is declared. For instance, if this statement is placed inside a loop, the 
variable shisewr will no longer be valid when the loop terminates. In technical 
lingo, it will “go out of scope.”) If nothing occurs to change the value at that 
lacation benveen these CWO assignment statcments, thisvar will be SCE equal fo a 
value of 179. 

The dereferenced pointer “charpointer can be used anywhere within a program 
that a char variable could be used. To print the value stored at the location 
pointed to by charpointer as a signed decimal integer, for instance, you could use 
the printf statement: 


printt("si\n",.*charpointer); 
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Mode 13h 


So what memory locations do you need to change in order to program video 
memory? And what values do you need to change them to? 

That depends on several things. Obviously, it depends on what sort of image 
you want to place on the display. Bur it also depends on what video mode the 
computer is currently in. 

The programs in this book are designed to run on the IBM VGA video 
adapter, variations on which can be found in the vast majority of current PCs. 
The VGA adapter can be operated in 24 different “official” modes and quite a 
few more unofficial ones. Some of these are text modes, which means that the 
numeric values represent text characters. The remaining modes are graphics 
modes. When the VGA adapter is placed in a graphics mode, the values placed in 
video memory represent the colors of the tiny dots on the video display, known 
as pixels, which make up all graphic images. 

In this book we'll use the WGA adapter in the “official” graphics mode known 
as mode 13h. (The “h’ after the 13 indicates that the number is in hexadecimal. 
In decimal this mode is known as mode 19, but the hexadecimal identiher ts 
more commonly used than the decimal one.) In this mode all graphics are 
constructed out of a matrix of 320 pixels horizontally and 200 pixels vertically. 
Each of these pixels can be in any of 256 different colors (which can, in turn, be 
chosen from a list of more than 256,000 different colors). 

Mode 13h is the most common mode for programming animated video games 
on the PC. There are a number of reasons for this, the main one being that it is 
the only standard VGA mode that supports 256 simultaneous colors on the 
display. Some VGA adapters offer additional 256-color modes — quite a few even 
offer modes in which 16 million different colors can be simultaneously present on 
the display — but none of these modes is standardized. They are programmed 
differently on different brands of adapters, and on many adapters they are simply 
not available. Furthermore, most of these modes feature higher resolutions — 
numbers of pixels — than mode 13h. Although this improves the appearance of 
the graphics, it also tends to slow down the speed of the animation, since a much 
larger amount of data must be moved around in the computers memory in order 
to draw and animate an image. Games that use the higher-resolution 256-color 
modes are already appearing on the market, bur for the moment they elt still 
outnumbered by lower-resolution games. A year or two from now, one of these 
modes may be the standard mode for video game development, but at present it is 
mode 13h that has that honor. Fortunately, most of the techniques that we'll 
discuss in this book for animating images on the mode 13h display can be used in 
higher-resolution modes with only minor changes to the program code, 
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setting the Video Mode 


To make our job easier, the code for turning mode 13h (or any other “official” 
VGA video mode) on and off ts built into the video card itself. We can use this 
code in a program by going through the built-in ROM BIOS, the set of program 
routines that are installed in the computer at the factory. However, many of the 
ROM BIOS routines — including the ones for setting the video mode — are 
best accessed through assembly language modules rather than through high-level 
programming languages such as C++, so in this book we're going to create a small 
library of assembly language routines for communicating with the ROM BIOS 
(as well as with video memory itself) and put them in a hle on the accompanying 
disk called SCREEN.ASM. We'll then link this file directly with our C++ 
programs, so that we can call these routines from our C++ code as though they 
were C++ functions. Chis file will be automatically assembled by Turbo 
Assembler (TASM), a utility program that comes as part of the full Borland C++ 
3.1 package, when its name ts included in a Borland PRJ hile. (For those readers 
who lack the full Borland C++ package with TASM, the already assembled 
version of this code is also included on the accompanying disk under the file 
name SCREEN.OBJ. Substitute this name for SCREEN.ASM in the project hles 
or make files for all programs in this book that reference it. TASM may be 
purchased separately for readers using 4.0.) 

There isn't space in this book for a full-scale primer on assembly language, 
though well rerurn to the subject at somewhat greater length in chapter 12, 
when we discuss program optimization, (A brief overview of assembly language 
programming is provided in Appendix B.) And you don’t really need a knowledge 
of assembly language to use these functions (though its helpful to know an 
assembler if you want to revise these functions or write some of your own). So 
that you wont be totally in the dark about how these functions work, I'll explain 
how some of the assembly language instructions and conventions work as they 
arise, but its not necessary that you grasp every little detail of this code. 

When we write an assembly language routine that can be called as a C+4 
function, we must begin it with a PROC statement: 


_setmode PROC 


This tells the assembler (the program that translates this assembly language code 
into a form that can be linked with a C++ program) that were about to create an 
assembly language procedure called _sermode. (When we write an assembly 
language procedure that is to be called by name from a C/C++ program, the 
name of that procedure must begin with an underscore, However, when we call it 
from C++, we must drop the underscore and refer to it by the name setenode(), 
without the underline.) We can then use the assembly languagre ARG directive to 
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tell the assembler that we'll be passing a single parameter to this procedure when 
we call it: 


ARG mode: WORD 


This 1 1& equivalent co declaring cl function int C++ with the function header 
sepnode(int mode). Now we can reference the label made in the text of the 
procedure, and the assembler will translate that reference into code referring to 
the value that we pass from C++. However, for this to work correctly, we must 
first include a piece ot boilerplate code to take care of the technical details: 


push bp 
mov bp,sp 


Dont worry about what this does. Just remember that, without it, the ARG 
directive wont work properly. 

We then must move the value of the mode parameter into AX, which ts a 
special memory location within the computers CPU known as a register: 


mov ax,Lmode] 


Translated into something resembling English, this instruction means “move the 
value in the memory location that we have labeled mode and place it in the 
special memory location known as AX.” Now that the video mode ts in location 
AX, we must place a 0 in the location known as AH: 


mov ah,Q 


Memory location AH ts actually part of memory location AX, though you 
dont really need to know that 1 aa order ta understand what this code does. 
Basically, we are telling the ROM BIOS that it should execute video function 0 
(which is the function that sets the VGA mode) to put the video display into the 
made stored in AX, which will be equal to the parameter we passed from C++. 
Then we execute this instruction: 
int 10h 
This calls the ROM BIOS itself to do the actual work of changing the video 
mode, All thars left to do is clean up the mess we made with the instructions that 
set up the computers memory for the AAG directive: 
pop bp 

Finally, we must execute a RET instruction vo tell the CPU thar its time to 
return control from this function back to the program thar called ir: 


ret 


And we must tell the assembler that the assembly language procedure is 
finished, with the ENDP directive: 


a) 


GARDENS OF IMAGINATION 


_setmode ENDP 


The complete SET MODE procedure appears in Listing 2-1. 





Seems Listing 2-1 The SETMODE procedure 


; Setmodelint mode) 
; Set VGA adapter to BI05 mode MODE 


_setmode PROC 
ARG mode : WORD 


push bp : Save BP 


r 
mov bp,5p ; Set up stack pointer 
mov ax,mode ; AX = video mode 
mov ah, , AH = function number 
int 10h : Call video BIOS 
pop bp ; Restore BP 
ret 


_setmode ENDP 


The semicolons in several of the program lines indicate that what follows is a 
comment to be ignored by the assembler. Because assembly language code tends 
to be rather obscure, it's a good idea to embed such comments wherever possible, 
to clarify the programmers intent. 

To put the VGA adapter into mode 13h, you can call this function from C++ 


like this: 
setmode(Ox13); 


Finding Video Memory 

Once youve put the VGA adapter into mode 13h, finding video memory is a 
piece of cake. It always begins at address AOO0:0000 (which is equivalent to a 
linear address of AOOOO hexadecimal) and continues for a total of 64,000 (or 
F800 hexadecimal) addresses thereafter. The last address tn mode 13h video 
memory is AQOO:F7FE (The remaining 1.535 bytes of the 64-kilobyte segment 
video memory are unused, since a segment ts 65,536 bytes long and there are 
only 64,000 pixels on the mode 13h display.) 

Changing the value stored in any of the addresses in this range will change the 
color of the pixel in the corresponding position on the video display. How can 
you tell which pixel corresponds to which memory address? In mode 13h the 
pixels on the display are arranged in 200 horizontal rows, each containing 320 
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Figure 2-1 Each address in video memory corresponds 
to a pixel on the video display 


pixels. The first location in video memory — thar is, the location designated by 
the address AQOO:0000 — corresponds to the first pixel in the first row of pixels 
at the top of the display, which is to say the pixel in the upper-left corner of the 
screen. [he second location — the one designated by address AO00:0001 — 
corresponds to the pixel immediately to the right of that pixel, And so on for the 
first row of the display, with the location designated by address AQO0:013F 
corresponding to the pixel in the upper-right corner of the display. The next 320 
memory locations correspond to the 320 pixels in the row immediately below 
this one, so that address AQ00:0140 corresponds to the pixel directly below the 
one in the upper-left corner. Each succeeding 320 addresses in video memory 
corresponds to another row of pixels Onl the display, moving from the top ee 
sequentially to the bottom one. The last address in video memory, AOOO:F/FF, 
corresponds to the pixel in the lower- “tight corner of the display (see Figure 2-1). 

With this information we can write a short program to paint the mode 13h 
video display entirely white. Such a program appears in Listing 2-2. 





GARDENS OF IMAGINATION 






tm Listing 2-2 The WHITEOUT.CPP program 


fi 

/f WHITEQUT Version 1.0 

if 

// Fills mode 13h video memory with a constant value of OxO0f, 
/f filling the display with white pixels 

ii 

/f Written by Christopher Lampton 

‘/ for Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 
Finclude <dos.h> 

Hinclude <conio.h> 
Ainclude “screen.h" 


VoId main(void) 
{ 


‘/ Save previous video mode: 
int oldmode=*(Cint *)MK_FP(Ox40,0x49): 


‘/ Create pointer to video memory: 
char far *screen=(char *}MK_FP(OxaQ00,0); 


if Set mode 13h: 
setmode(Ox13); 


if Fall video memory with a constant value: 
for Cunsigned int i=0; i<64000; i++) screenlij=0x0f; 


// Wait for user to press a key: 
while €'kbhitt)); 


// Reset original video mode: 
setmode(oldmode) ; 


At the beginning of the program listing, after the initial comments, is a list of 
the header hles to be included. The SCREEN.H header hile ts on the 
accompanying disk and must be included in all programs that use the functions 
in the SCREEN.ASM hile. The others are standard Borland headers. The 
program itself consists of a single mai() function. The first line of this function 
reads the value of the previously set video mode, which is normally stored at 
memory address 0040-0049, into the #vt variable oldmode, so that the mode can 
be restored larer. (If the old mode was never restored, the user would exit the 
program to find that the display was still in mode 13h.) 
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The MK_FP macro is then used to point the pointer variable screen to the 
start of video memory. The setrrede() function, which was introduced a few pages 
aga, 1s called to set the screen to mode 13h. At that point, all that's needed to 
paint the display white is a simple for() loop, which iterates the unsigned integer 
variable through all 64,000 offsets in the video memory segment. We can access 
these locations by treating the pointer variable screen as an array of char beginning 
at address AOOO:0000, The array offset s — which should not be confused with 
the offset portion of a memory address, though its function is similar — is added 
to the address of the start of the array, so the successive values of ¢ cause the 
assignment statement weve placed in the loop to place the constant value 15 
throughout video memory. The last few lines wait for the user to press a key 
(using the 4@/z¢() function from the CONIO.H file) and restore the old video 
mode (using the same sefmode() function that we used to set mode 13h). 

Run the program by typing WHITEOUT at the DOS prompt and watch 
what happens: The screen fills rapidly with white pixels. If you have a fast 
machine, it will hll so quickly with this single color that the change will appear 
nearly instantaneous. 


The VGA Palette 


Why does the screen fll with the color white and not, say, Mauve or chartreuse? 
The key is in the program statement 


for Cunsigned int i=0; i<64000; it+) screenLil=O0x0f; 


This is the statement that assigns a value of OxOf (or decimal 15) to each 
memory location within mode 13h video memory. Try changing this number to 
some other number in the range 0 to 255 (hexadecimal 00 to FF) and 
recompiling the program. If you change the number to Ox(e (decimal 14), the 
screen will fill with the color yellow instead of white. If you change the number 
to Ox1b (decimal 27), the screen will fll with the color gray. And so forth. 

Each of these numbers, when placed in a mode 13h video memory location, 
causes a different color of pixel to appear on the display. How do we know what 
numbers correspond to what colors of pixel? The VGA adapter keeps a list of 256 
colors, each of which corresponds to one of the 256 possible values that can be 
stored in each video memory location. This list of colors is called the palette. The 
first color in the palette list corresponds to a value of 0 stored in video memory, 
the second color in the list corresponds tO 2 value of l ‘ and Ch forth —— up tt the 
256th color in the list, which corresponds to a value of 255. As it happens, the 
sixteenth color in the list is white, which is why placing a value of 15 (which 
corresponds to the sixteenth color in the palette) in video memory causes a white 
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pixel to appear on the display. The fifteenth color in the list is yellow, which is 
why placing a value of 14 in video memory causes a yellow pixel to appear on the 
display. The twenty-eighth color in the list is gray. And so forth. 

As you might guess, there's a built-in function in the VGA BIOS that allows 
us to change the colors in the palette list. Listing 2-3 contains a short assembly 
language procedure (which can be found on the disk in the fle SCREEN.ASM) 
that can be called from (++ to set the palette. The syntax for calling this 
function is 


setpalette(color_regs); 


where color_regs is a far pointer to an array of ear, This array must have 768 
elements in it, The first three elements in this array contain a color descriptor for 
the first color in the palette, the second three elements contain a color descriptor 
for the second color in the palette, and S) OF. Each of these color descriptors 
consists of three values in the range 0 to 63, where the first value represents the 
blue Intensity of the color, the second value the ereen Intensity of the color, and 
the third the red intensity of the color. A value of 0 indicates minimum intensity 
in that component of the color, and a value of 63 represents a maximum 
intensity in that component; all other values represent an intensity between these 
extremes. Thus a color descriptor for a pure, bright shade of red would consist of 
the values 00,63. A moderate shade of gray would consist of the values 32,32,32. 
The color white would consist of the values 63,63,63. And so on. 





| Listing 2-3 Tne SETPALETTE procedure 


> setpalette(char far *color_regs,intfirstreg,int numregs) 
: Set VGA color registers, beginning with FIRSTREG and 
continuing for NUMREGS to the color values in COLOR_REGS 


! 


_setpalette PROC 
ARG regs: DWORD 
push bp 
mov bp,sp 
les dx,regs 
mov ah,10h 


save BP 

Set up stack pointer 

Point ES:5X at palette registers 
Specify BIOS function 10h 


Se ee 


mov al,Jéh : ...subfunction 12h 

mov bx,0 » Start with first register 
mov cx,100h ; Set all 256 (100h) registers 
int 10h » Call video BIOS 

pop bp ; Restore BP 

ret 


_setpalette ENDP 


————— 
} 
| 


a) 
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When you turn the computer on, the VGA BIOS automatically sets up a 
default palette. Listing 2-4 contains a short program that will display the default 
mode 13h palette as a 16 by 16 matrix of small squares, with the first row of 16 
squares representing the first 16 colors of the palette, the second row of 16 
squares representing the next 16 colors of the palette, and so on. This program, 
which can be found on the disk as PALETTE.CPP (and executed by typing 
PALETTE at the DOS prompr). is nearly identical to the earlier 
WHITEQUT.CPP program, The only difference is in the for() loop, which is 
now a nested sequence of for() loops. The outermost loop runs through all 256 
palette-colored squares. The two inner loops cycle through the 12 vertical and 20 
horizontal pixels in each square. The assignment statement that sets the pixels 
uses the division (/) and modulus (%) operators to calculate the video memory 
offset corresponding to the upper-left corner of the square, then adds in the x and 
y positions of the pixels within the square to get the exact memory address to 
change. We'll talk more about this technique of identifying video memory 
locations in a moment, so you might want to come back and look at this 
program again after you've finished reading this chapter. The ourput from the 
PALETTE program is shown (as a gray-scale image) in Figure 2-2. 





Listing 2-4 The PALETTE.CPP program 


‘* PALETTE Version 1.0 


‘/ Draws the mode 13h default palette as a matrix of 
// squares on the video display 


ff Written by Christopher Lampton 
// for Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 
Hinclude <dos.h> 

Rinclude <conio.h> 
Ainclude "“screen.h" 


Void main(void) 
{ 


f/f Save previous video mode: 
Int oldmode="Cint *)MEK_FPCOx40,0x49): 


‘f Create pointer to video memory: 
char far *screen=(char *}MK_FP(Oxa000,0); 


cee hued Of ey page 
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roared from preston pape 
‘* Set mode 13h: 
setmode(Ox135): 


ff Draw @ 16x16 matrix of squares in the default colors 
for(int square=0; square<254; square++) 
fortint y=O; y<l2: y+) 
forflint x=D0; x<20; x++) 
screenlLsquare/ 16*3840+squares16*20+y*4320+x J=square; 


‘f Wait for user to press a key: 
while ('kbhitt)); 


‘/ Reset original video mode: 
setmode(oldmode) ; 


A Screen-Clearing Function 


We need to add one more function to our SCREEN.ASM file betore we can start 
doing some serious graphics coding. It will be a function for clearing the video 
display, to eliminate any trash that might have been left there by earlier programs 
(or to clear one screen off the display to make room for another). It would be 
easy enough to adapt the earlier WHITEQUT program for this purpose, 
changing the value of 15 that WHITEOUT stores in video memory to a value of 
0 (which represents the color black in the default palette). Bur to guarantee that 
were getting maximum speed and efheiency for our programming money, well 
write this function in assembly language instead. 





Figure 2-2 The output from the PALETTE.CRP program, showing 
all 256 colors in the default palette (here represented in gray-scale) 


30 
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The completed function appears in Listing 2-5. It's called CLS, short for 
(Lear Screen. It can be called from C++ like this: 


cls(screen_address) 


The parameter screen_address is the address of the first location in video 
memory. You might wonder why we dont simply hardceode this address into the 
function itself, since mode 13h video memory is always located in the same place. 
Later, however, well want to draw our screen images in locations other than 
video memory, then move them all at once to video memory. Passing a screen 
address parameter to ef) function will allow us to do this without writing a 
whole new battery of functions. 

The key instruction in the program listing is REP STOSD. This is one of the 
so-called string instructions offered by the 80x86 series of microprocessors (the 
series that all IBM-compatible microcomputers are based on). This instruction 
hills the entire video display, by inself, with the value stored in the AX memory 
register. Before it executes, the program places a () in this register, so that the 
video display is cleared to black. Assembly language programmers will recognize 
that this particular string instruction is one that will only work on 80386 or 
better microprocessors, because it moves data 32 bits (that is, 4 bytes) at a time. 
Were using this instruction because state-of-the-art VGA boards are connected to 
the computers CPU via 32-bit interfaces and the REP STOSD instruction will 
execute twice as fast as the 16-bit REP STOSW instruction that is more typically 
used to perform this task. (On older graphics boards, with 8- or 16-bit interfaces, 
it probably wont provide any noticeable improvement in speed over the 16-bit 
instruction.) 





Listing 2-5 The CLS procedure 


; clhstchar far *screen_adr) 
; Clear video memory or offscreen buffer at 
; SCREEN_ADR to zeroes 


_tls PROC 
ARG screen: DWORD 
push bp ; Save BP 
mow bp, sp ; Set up stack pointer 
push di ; save DO] register 
Les di,screen ; Point ES:01 at screen 
mov cx,oCREEN WIDTH/4 * SCREEN_HEIGHT ; Count pixels 
mov ax, ; store zero values... 
rep stosd ; «eetn all of video memory 
pop di ; Restore DI 


DorR, itive a eS fate 





GARDENS OF IMAGINATION 
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pop bp ; Restore BP 
ret 
_cls  ENDP 


Building a Wireframe Maze 


As promised in the last chapter, we are now going to develop a program that 
builds a wireframe representation of a maze on the computers video display. The 
trickiest part of drawing a wireframe representation of a maze is drawing the 
wires themselves, What we need is a function that will connect any two pixels on 
the video display with a line. Alchough the Borland Graphics Interface has a 
built-in line drawing function, it doesn’t work in mode 13h (and tsn't necessarily 
fast enough for our purposes anyway). So we'll implement our own line-drawing 
function. Even if YOu plan to use the line- -drawing function | in Your favorite 
graphics library instead, you shouldnt skip over the description of how our line- 
drawing function performs its magic, since well be using some of the same 
techniques in later chapters to scale bitmaps. 


The Cartesian Coordinate System 


Video memory, as we have seen, is a series of memory locations corresponding to 
the pixels on the video display in row-and-column order, with the top row of 320 
pixels on the display corresponding to the first 320 locations in video memory, 
the second topmost row of 320 pixels on the display corresponding to the second 
320 locations in video memory, and so forth. However, this isnt always the best 
way to visualize either video memory or the video display. Throughout this book 
well lean heavily on a more abstract but useful system for identifying the 
positions of pixels on the screen — the x and y coordinates of a Cartesian 
coordinate system. 

The Cartesian coordinate system, invented by the French philosopher Rend 
Descartes in the seventeenth century, is commonly used in algebra and geometry 
for the graphing of equations. If you've ever taken a course in high school level 
mathematics, youve probably run across it. The Cartesian coordinate system 
identifies points on a plane by their positions relative to a pair of lines, one 
horizontal and one vertical, on which individual points correspond to numbers. 
These lines are called the horizontal and vertical axes (plural of axis) of the 
coordinate system (see Figure 2-3), 

Each point on the Cartesian plane — the fat area defined by the nwo axes of 
the coordinate system — can be identihed by a pair of numbers referred to as a 
coordinate pair, To learn what coordinate pair corresponds to a given point, you 
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Figure 2-3 A Cartesian system defined by honzontal and 
Vertical axes 


must draw a vertical line from that point to the nearest point on the horizontal 
axis, and a horizontal line from that point to the nearest point on the vertical 
axis. The points at which these lines cross the horizontal and vertical axes, 
respectively, are called the x and y coordinates of the point. The point in Figure 
2-3, for instance, has x and y coordinates of 7 and 4. 

The computer screen is more or less flat, so we can imagine it as a kind of 
Cartesian plane, with the vertical axis running along the left edge of the display 
and the horizontal axis running along the top. In a traditional Cartesian 
coordinate system, the coordinates run from left to right on the horizontal axis 
(which is usually referred to as the x axis), and from bottom to top on the vertical 
axis (which is usually referred to as the y axis), Bur when describing a computer 
display in Cartesian terms, the vertical axis is usually flipped upside down so that 
the numbers run from top to bottom, to correspond to the way in which video 
memory addresses grow larger when moving down the display (see Figure 2-4). 
This makes the translation from Cartesian coordinates to video addresses a little simpler. 


Plotting Pixels 


If the video display is a Cartesian coordinate system, then every pixel on it can be 
described by a pair of XY coordinates, relatrve to the horizontal and vertical axes 


a 
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Figure 2-4 Coordinates on the y axis arow larger moving down the display 


that we described in the last paragraph, (The two axes don't necessarily have to be 
in the positions that I ascribed to them. Although these particular coordinate axes 
are the ones traditionally used to describe the video display, we can move the axes 
pretty much anywhere on or off the display, as you'll see later in this book.) 

In the Cartesian coordinate system depicted in Figure 2-5, the pixel in the 
upper-left corner of the display corresponds to the 0 positions on both the 
horizontal and vertical axes, so it is usually said to be at x,y coordinates of 0,0. 





Figure 2-5 in this Cartesian coordinate 
system, the pixel is at 0.0 
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This position is referred to as the origin of the coordinate system, because it is the 
point at which the numbering systems on both of the axes begin. A pixel in the 
middle of the video display in mode 14h would have x.y coordinates of 160,100. 
To change the color of a pixel at a given x,y coordinate location, we must first 
learn which offset within video memory corresponds to that location, then 
change the value stored at that address. Finding the offset within video memory 
that corresponds to a given coordinate pair is as easy as this instruction: 
int offset = ¥ *-320 + x; 


After this instruction is executed, the ft variable offset will be equal to the 
offset within video memory corresponding to the pixel at screen coordinates x 
and y. Because each line of pixels on the display consists of 320 pixels, y (which 
represents the number of lines from the top of the display to the line containing 
the pixel) must be multiplied by 320, then added to x (which represents the 
number of columns from the left side of the display to the column containing the 
pixel) co obtain this value. 

We can set this pixel to the color white with the instruction 


screenloffset] = 15; 


It's assumed here that the pointer variable sereem is pointing to the start of 
video memory and that the default palette is in use. 

Once we know the offset of the pixel at a given pair of coordinates, its simple 
to find the offset of the pixel to the immediate left or right of that pixel. Simply 
subtract | from or add | to the offset. Similarly, to find the offser of the pixel 
immediately below the pixel at a given offset, we add 320 to the offset, and to 
find the offser immediately above the pixel at a given offset, we subtract 320 from 
the offset. 


Drawing a Line 


And that brings us back to the problem of drawing a line. It's rare that we'll only 
need to change the color of individual pixels on the display. In depicting a 
wireframe maze, its far more important that we be able to change the color of 
entire sequences of pixels to form lines. This isn't a trivial problem. In fact, it’s 
one of the most complex problems that we'll be tackling in this book, (Dont let 
that frighten you away, though. Once you get through this discussion of 
computer line drawing, the rest of this book will be a snap!) 

We'll need to make a distinction in this discussion berween points and pixels. 
A point is a mathematical concept that can be defined by its coordinate position 
within a Cartesian plane. As youll probably remember from grade school 
geometry class, a point has no width, depth, or breadth, and there are an infinite 
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number of them in a line or in a plane. In fact, there are an infinite number of 
points berween any two other points on a line, no matter how close those points 
are ta one another. 

Pixels are the best approximation that we have for representing mathematical 
points on a video display, but there are some significant differences between 
pixels and points. Pixels do have width and breadth, and maybe even a little 
depth, but they're small enough that we can pretend that they don’t. There are a 
hnite number of pixels on the video display — 64,000 in mode 13h — and so 
there have to be a finite number of pixels in any line we draw on the display, It ts 
possible, even somewhat trivial, to find pwo pixels on the video display that have 
no additional pixels berween them. 

Because there are an infinite number of points in a plane, and an infinite 
number of points between any other nwo points, the x.y coordinates of a point in 
a Cartesian coordinate system can have fractional values. It’s perfectly legitimate 
to describe a point as being at coordinates 4.51232,7.177249 within a Cartesian 
plane, to cite but a single example. Pixels, on the other hand, can only have 
integral coordinates, without fractional values. To represent a point with 
fractional coordinates by a pixel with integer coordinates, we have to round the 
coordinates of the point to the nearest whole numbers to obtain the coordinates 
of the pixel that would best represent that point. The pixel most nearly 
equivalent to the point mentioned earlier in this paragraph would be the one ar 
coordinates 5,7. 


Endpoints 


In geometry, a line is a sequence of points. However, to describe a line in terms of 
a Cartesian coordinate system, its not necessary to specify the coordinates of 
every point that makes it up. (That wouldnt even be possible, since wed have to 
specify an infinite number of coordinates.) A better method of describing a line, 
and the one that well be using in this chapter, is to specify the x,y coordinates of 
its endpoints — that is, the points at which it stops and starts. (Since lines dont 
necessarily have a direction, cither end can be the starting point or the stopping 
point. In practice, the starting point of a line will be the point at which we start 
drawing it and the stopping point will be the point where we stop.) The line in 
Figure 2-6, for instance, starts at coordinates 2,1 and ends at coordinates 3,4 (or 
vice versa, depending on which end we start drawing it at). It's not necessary to 
specify the coordinates of any other points on the line because they can be 
calculated from these end points. I'll show you how to do that in a moment. 

On a computer video display, a line is a sequence of pixels, We can describe a 
line on the video display in the same way that we describe a geometric line, by 
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Figure 2-6 A line from coordinates ?,1 to 
coordinates 3.4 


the coordinates of its endpoints. And we can draw the line as a sequence of pixels 
running from one endpoint to the other. Burt co do that, we'll need to hgure out 
which pixels on the display come closest to representing some of the inhnite 
number of points that make up the line. (Since pixels have width and breadth, we 
can imagine that each pixel is made up of an infinite number of points, so when 
we draw a line using a finite number of pixels, we are also drawing an infinite 
number of points.) This is no mean trick. 


Horizontal and Vertical Lines 
Some types of lines are easier to draw than others. The easiest of all are horizontal 
and vertical lines. 

A horizontal line can be defined as a line that has the same y coordinates at 
both endpoints, but different x coordinates. The offset of every pixel in a 
horizontal line is 1 more than the offset of the pixel to its immediate left, and 1] 
less than the offset of the pixel to its immediate right. Similarly, the offset of 
every pixel in a vertical line is 320 more than the pixel above it, and 320 less than 
the pixel below it (see Figure 2-7), To draw a horizontal line, we first calculate the 
offset of the leftmost pixel in the line, change the color of that pixel, then add 
one repeatedly to the offset, changing colors as we go. To draw a vertical line, we 
calculate the offset of the topmost pixel, change its color, and add 320 repeatedly 
to the offset to get the offsets of the remaining pixels. 

The program in Listing 2-6, for instance, draws a horizontal line across the 
middle of the mode 13h display, starting 10 pixels from the lett side of the screen 
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Figure 2-7 The offset of every pixel ina 
horizontal line is 1 more than the pixel to 
its feft, and 1 less than the pixel to: its right: 
The offset oF every pixel in a vertical line is 
§ 320 more than the pixel above it, and 320 

~ (ess than the pixel below it 





and ending 10 pixels from the right. The setup is identical to that in the earlier 
WHITEOQUT and PALETTE programs. The line drawing itself is done by a 
for? loop. Before this loop begins, the integer variables startx and starty are set to 
the x,y coordinates of the first pixel in the line. Then these coordinates are used 
to calculate the video memory offset of thar pixel, using the formula that we 
introduced a few paragraphs ago. The for() loop simply steps the integer variable : 
through the 300 pixels on the line. 





i Listing 2-6 The HORZLINE program 


ff HORZLINE Version 1.0 
‘/ Draws a horizontal Line across the mode 13h display 


‘i Written by Christopher Lampton 
‘ff for Gardens of Imagination “Waite Group Press} 


Hinclude <stdio.h> 
finclude <dos.h> 

finclude <conio.h> 
#Hinclude “"screen.h" 


Void main(void) 
f 


‘? Save previous video mode: 
int. oldmode=*(int *)MK_FPCOx40,0x49); 
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ff Create pointer to video memory: 
char far “screen=(char *)MK_FP(Oxa000,0); 


ff Set mode 13h: 
setmode(Qx13); 


ff Set starting coordinates for Line: 
int startx=10; 
int starty=100; 


// Calculate video memory offset of coordinates: 
int offset=starty*s20+startx; 


f/ Draw the Line: 
for (int 1=0; 7<300; 144) screenloffset+iJ=15; 


ff Wait for user to press a key: 
while ('kbhit)); 


// Reset original video mode: 
setmodelaldmode); 


A vertical line can be drawn in pretty much the same manner, as shown in 
Listing 2-7. The major difference is that the value of the offset ¢ must be 
incremented by 320 for each successive pixel in the line, moving the offset of the 
pixel a full screen line deeper into video memory. 





‘Listing 2-7 The VERTLINE program 


if 

‘/ VERTLINE Version 1.0 

ii 

‘/ Draws a vertical Line down the mode 13h display 
fi 


ff Written by Christopher Lampton 
‘/ for Gardens of Imagination (Waite Group Press) 


finelude <stdio.h> 
Finclude <dos,h> 

Yinclude <conio.h> 
Finclude “sereen.h" 


void main(void) 
{ 


‘/ Save previous video mode: 
int oldmode=*Cint *)MK_FP(O0x40,0x49); 


CORnmnEa OM mext Page 
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coated fro PTEtNOnS Pape 
‘/ Create pointer to video memory: 
char far *screen=(char *)MK_FPCOxa000,0); 


ff Set mode 13h: 
setmode(Qxn13); 


ff Set starting coordinates for Line: 
int startx=160; 
int starty=10; 


‘/ Calculate video memory offset of coordinates: 
int of fset=starty*320+startx; 


// Draw the Line: 
fortunsigned int i=0; 1<57600; i#=420) screenloffset+iJ=15; 


// Wait for user to press a key: 
while ('kbhit¢)); 


if Reset original video mode: 
setmode(oldmode) ; 


Lines of Arbitrary Slope 

The real trick for a graphics programmer, though, is in writing a routine that can 
draw a line between any two arbitrary points on the video display. This takes 
some ingenuity. Fortunately, this ingenuity was demonstrated nearly three 
decades ago by a programmer named Bresenham, after whom the most popular 
line drawing algorithm is named. In this chapter we'll implement a version of 
Bresenham’'s Algorithm for the mode 13h display, 

The key ae drawing ofl arbitrary line | 1S hguring Our how much the position of 
each pixel on the line must change from the position of the pixel preceding it. In 
the horizontal and vertical line drawing programs we presented in the previous 
section, this was no problem at all: We changed the position of the pixel by one 
horizontal position for horizontal lines and one vertical position tor vertical lines. 

To figure out how much the position of each pixel changes in a line of 
arbitrary slope, we must first calculate the amount of change in each dimension. 
This t Isnt particularly difficult. lt requires only thar We calculate the line's slope. In 
mathematics the slope of a line is the change in the y coordinate from one end of 
a line to the other divided by the change in the x coordinate from one end to the 
other. For instance, the diagonal line in Figure 2-8 changes by 8 coordinates in 
the x position and § coordinates in the y position, from the left end of the line to 
the right. Thus we say that this line has a slope of 8/8 or 1. This tells us how 
much the y coordinate changes from one pixel to the next along the line, if we 
increment the x coordinate by | on each pixel. In this case ir changes by 1. Invert 
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the slope — Hip it top to borterm — and ir tells us how much the x coordinate 
would need to change from one end of the line to the other while the y 
coordinate is being incremented by 1. Since 8/8 is the same inverted, this change 
is also 1. So to draw this diagonal line, we would need to change the pixel 
coordinates by | in the y dimension while incrementing the x coordinate, or by | 
in the x dimension while incrementing the y coordinate. 

Unfortunately, not all line slopes are integral. Most contain fractions, meaning 
that the coordinates of the pixel must be changed by a fractional amount in 
either the x or y dimensions. For instance, the line in Figure 2-9 has a slope of 
1/2, because it changes by cwice as much tn the horizontal dimension over the 
length of the line as in the vertical dimension. This tells us that the y coordinate 
should be incremented by 1/2 for each pixel, while the x coordinate 1s being 
incremented by 1. Unfortunately, there's no such thing as half a pixel. We could 
draw the same line by flipping the slope over and incrementing the x coordinate 
by 2 while incrementing the y coordinate by 1, but then the line would have 
holes in it, because wed be skipping pixels. 

The only solution that works for pixel-oriented video displays of the sort 
produced by the VGA adapter is to ignore fractional changes in pixel position 
until they've added up to at least 1, then advance the pixel to the next coordinate 
in that position. For instance, the vertical position of the pixels in the line in 
Figure 2-10 may only need to be incremented by 1/2 a coordinate every time the 
horizontal position is incremented by 1, bur in real video terms ir needs to be 
incremented by a full coordinate every time the horizontal position ts 
incremented by 2. So we can draw this line if we increment the y position of the 
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pixels once every omer time we increment the x position of the pixels, as shown in 
Figure 2-10, 

In fact, we can use this method to draw lines with any slope at all. The 
simplest way to implement this system is to maintain fractional values for the x,y 
coordinates of the pixels, but draw the pixels on the display using a pixel drawing 
function that truncates the fractional portion of the coordinate values to the 
nearest integer when calculating the video memory offsets of the pixels. This will 
cause the pixel to automatically advance to the next position when the fractional 
value increases to the next integer — when a couple of 1/2 increments add up to 
an increment of 1, for instance. A simple line-drawing function that would draw 
any line with a slope from 0 to | (that is, from horizontal to diagonal) could be 
written by calculating the slope, incrementing the x coordinate by | for every 
pixel of the line, and adding the slope to the y coordinate for every pixel. To draw 
a line with a slope greater than 1 (thar is, from diagonal to vertical), we would 
simply invert the slope, increment the y coordinate by 1 for each pixel, and add 
the inverted slope to the x coordinate. We could then call a pixel-drawing 
function to draw each pixel as its position is calculated. 

But we dont want to deal with fractions in our line-drawing routine. I'll talk 
more about the reasons for this when we discuss optimization, but the basic 
reason is that fractions are slow. The line-drawing function that we develop tn 
this chapter should avoid fractions ar all cost, using only integer math. The trick 
to avoiding fractions Is to avoid division — that is, not to calculate the slope — 





Figure 2-10 The line in Figure 2-9 drawn 
by incrementing the y pixel position once 
for every time that the « pixel position is 
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because it is this division that produces the fractions in the first place. But how 
can we tell how much to advance the pixel position if we dont calculate the 
slope? 


Bresenham’'s Algorithm 

Bear in mind that division is really nothing more than repeated subtraction. If we 
repeatedly subtract one number from another number until the remaining value 
is less than the number that we are subtracting, then we have effectively divided 
the second number by the first. The number of repetitions we need to subtract 
the first number from the second is the quotient of the division, and the amount 
left over is the remainder. For instance, we can subtract 2 five times from 11, 
leaving a result of 1 — which is smaller than 2. Thus 11 divided by 2 ts 5, with a 
remainder of 1. 

Similarly, if we add a number repeatedly to itself uncil it is larger chan a second 
number, then the number of additions that we have performed is the quotient of 
the frst number divided into the second, plus 1. If we then subtract the second 
number from the hrst, we get the remainder. 

This process, which we might call incremental division, is the secret to 
implementing Bresenham’s algorithm. First we calculate the change in the x and y 
coordinates along the length of the line. (This is simply a matter of subtracting 
the beginning x and y coordinates from the ending x and y coordinates and 
taking the absolute values of the results.) Call these owo values xdi/fand yes Uf 
the slope is less than 1 — thar ts, if waif is greater than yaiff— we increment the 
*% coordinate by 1 after drawing each pixel, To determine when to increment the 
y coordinate, we create a value called the errer term, which is initially ser to 0. We 
eall it the error term because it will tell us how far our pixelated line is deviating 
from a geometric line. After drawing each pixel, we add yeiff to the error term 
and check to see if the value of the error term is greater than xdiff If it isnt, we 
leave the y coordinate as it ts. If it ts, then our y coordinate has deviated by (at 
least) a full pixel position from the actual geometric position of the 
corresponding point on the line, so we increment the y coordinate and subtract 
«aiff from the error term. 

To see how this works, imagine that xdi/f is 42 and yeiff is 20. The slope of 
the line would be 20/42 or 10/21. We would need to increment the y coordinate 
10 times for every time that we increment the x coordinate 2] times. The error 
cerm helps us do this. Adding yd#/f to the initial error term value of 0 gives us a 
value of 20. We compare this to xdffand see that the value of the error term has 
not yet exceeded the value of xdiff so we dont advance the y coordinate. The 
next time we add y¢#/F to the error term, the result is a value of 40, which still 
doesnt exceed the value of xa/f, so we leave the y coordinate untouched once 
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again. But the third time the value of the error term becomes 60, which does 
exceed the value of xai/f so we increment the y coordinate. This means that the 
first three pixels of the line are drawn at the same y coordinate, but the y 
coordinate of the fourth pixel is advanced by 1. We then subtract the value of 
xaiff trom the error term, producing an error term value of 18. Because the error 
term now starts out at a higher value, we will only be able to add yez/f to it twice 
before it exceeds the value of xdi/f As a result, the y coordinate is incremented 
atter only two more pixels. This will continue to be the case for the next 19 
pixels, at which point the initial value of the error term will have returned to 0. 
The process then repeats, with three pixels in a row having the same y coordinate, 
then only two pixels in a row for the next 20 repetitions of the process. The 
result? The y coordinate will be incremented 10 times for every 21 times thar the 
x coordinate will be incremented, just as if we had calculated the slope. 

If the slope is greater than | — thar is, if perf is larger than xeiff— then we 
must do this the other way around, We increment the y coordinate by | for each 
pixel on the line, adding xf to the error term after each pixel is drawn and 
incrementing the y coordinate when the error term becomes greater than ydiff. 
We also must make allowance for the direction in which the line is moving — 
that is, whether its going from a small coordinate to a large coordinate or vice 
versa in the x and y dimensions. When going from a small coordinate to a large 
coordinate — we'll call this the positive direction — we must increment the pixel 
coordinates in that dimension; but if were going from a large coordinate to a 
small one (the negative direction), we must decrement them. 

Listing 2-8 shows how all of this is done in an actual C++ implementation of 
Bresenham’s algorithm, which is included on the disk in the fle BRESN.CPP. To 
use this function, you must include the BRESN.H header in your programs. It 
can be called using this syntax: 

Linedraw(x1,y1,x2,ye,color,screen) ; 
The first four parameters are the starting and ending coordinates of the line. 


The caler parameter 1s the number of the palette color in which the line is to be 
drawn and screen is a pointer to the video display (or to an offscreen butter). 






Listing 2-8 The linedraw() function 


void Linedrawlint xl,int yl,int x2,int y2,int color, 
char far *screen) 


{ 


int ylunit,x_unit; // Variables for amount of change 
‘f in x and ¥ 
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int offset=y1"*320exn1; // Calculate offset into video RAM 


int ydiff=yv2-¥1; ff Caleulate difference between 
// oy coordinates 
if (yditf<0) @ ff If the line moves in the negative 
ff direction 
yditf=-ydiff; f/f ...get absolute value of difference 
¥ unit=-320; ff ...and set negative unit in 
ff oy dimension 
} 
else y_unit=320; // Else set positive unit in 
ff oy dimension 
int xdiff=x2-x1; ‘f Calculate difference between 
ff & coordinates 
if (xdiff<0) ¢ ff It the line moves in the 
‘f/f negative direction 
xdift=—xdiff; ff ...get absolute value of 
ff ditference 
X_unit=-1; ‘/ ...and set negative unit 
ff ain « dimension 
} 
else xunit=1; // Else set positive unit jin 
‘fy dimension 
int error_term=0; ‘f/f Initialize error term 


if (xdiff>yditf) { // If difference is bigger in 
‘f/f os dimension 
int Length=xdiff+1; ff aeeprepare to count off in 
‘fo x direction 
for (int 1=0; i<length; i++) € /#/ Loop through points 
ff in x direction 


screenloffsetJ=color; ‘/ Set the next pixel in the 
ff Line to COLOR 
of fset+=x_unit; ‘/ Bove offset to next pixel 
‘if in x direction 
error _termt=ydiff; // Check to see if move 
ff required in y¥ direction 
if Cerror_term>xdiff) { fi Tf so... 
error _term-=xdiff; ff ...reset error term 
offset+=y_unit; ff ...8nd move offset to next 
‘/ pixel in y dir. 
} 
} 
} | 
else f{ ff If difference is bigger in 
‘i oy dimension 
int length=ydiff+1; // ...prepare to count off in 


ff oy direction 
for Cint 7=0; i<length; i++) { // Loop through points 
f/f in y direction 
screenloffsetJ=color; ‘/ Set the next pixel in the 
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coninued frown previews page 


/f Line to COLOR 


offset+=y_unit; ‘if Move offset to next pixel 
ff in y¥ direction 
error_termt=xdiff; ff Check to see if move 
ff required in x direction 
if (error_term>0) f ff Tf eo... 
error_term-=ydiff; ff ...Peset error term 
offsett=x_unit; ff ...and move offset to next 


‘f/f pixel in x dir. 


This function divides neatly into two parts, one for lines with slopes less than 
1 (where xeliff Is greater than yalif ), and one for lines with slopes greater than | 
(where yediffis greater than xdiff). (Lines with a slope of precisely 1 can be 
handled by either part.) The variable x_wnit is set to either positive or negative 1, 
depending on whether the line is moving in the positive or negative direction 
(that is, from lower to higher x or vice versa). Similarly, the variable y_amit is set 
to positive or negative 320. These variables are then added to the pixel positions 
to increment them from one position to the next in the corresponding 
dimensions. 

The variable errer_term is initialized to 0 and either diff (for lines with slope 
less than 1) or «aiff (for lines with slope greater than 1) is added to it repeatedly, 
until it exceeds the value of either xdiffor ydiff (whichever is not being added to 
it for the current slope). Then the pixel is incremented in the appropriate 
dimension, ydiff (or xdiff) is subtracted from errer_term and the process begins 
again, until the end of the line is reached. A fer() loop is used to increment the 
pixel coordinate in either the x or y dimension from one end of the line to the other. 


At Last ... the Maze 


We'll use this tmplementation of Bresenham’s algorithm to draw the “wires” in 
our wireframe maze. To create a wireframe maze, we must do two things: Design 
a data structure for storing the maze in the computers memory, and design an 
algorithm for drawing the maze on the screen. 

The first of these is the easier problem to solve. If we restrict ourselves to 
mazes that can be depicted on a piece of graph paper using horizontal and 
vertical lines that correspond to the graph lines, then we can store a description of 
a maze as a two-dimensional array of bytes (that is, as a two-dimensional char 
array). Consider, by way of example, the maze in Figure 2-11, which has been 
drawn on a piece of graph paper. Each square on the graph paper represents a 
single position in the maze, Squares that have been shaded are wall squares — that 
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Figure 2-11 A mazé drawn.on a sheet of 
graph paper 


is, impassable squares in which solid cement extends from the Hoor to the ceiling. 
An adventurer wandering through this maze would not be able to enter these 
squares. Unshaded squares are empty squares, in which an adventurer can travel. 

Every square in this maze can be given a coordinate position, similar to the 
way in which we give coordinate positions to pixels on the video display. If we 
place the origin of the maze coordinate system at the upper-left corner, then the 
square in that corner would have x,y coordinates of 0,0, The square to its 
immediate right would have x,y coordinates of 1,0. The square immediately 
below it would have x,y coordinates of 0,1. And so forth. 

We can store such a maze in the computer as a 16 by 16 array of char, like this: 


char mazelil6]Cié6lj=t 
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The elements of this array that are set to 1 represene the shaded squares in the 
maze, while the elements that are set to 0 represent open squares. (It may occur 
to you that we could represent this maze using only a bit per square rather than a 
full byte, but the byte representation will prove useful in the more sophisticated 
mazes that we will develop later in this book.) 

To locate our position within the maze, it would be useful to have a data 
structure for storing x,y coordinates. We'll define such a structure like this: 
struct xy t 


Int x,¥; 
}; 


Now, how do we 0 about drawing the maze on the display? 


One Square ata Time 


Imagine yourself standing in the middle of a maze, looking inte the distance. 
Imagine yourself standing in tl idle of looking he d 

Vhat would you see? Probably, you'd see something like the wireframe maze 
What would you see? Probably, youd hing like th f 
representation in Figure 2-12 (albete with the addition of such real world frills as 
colors and textures). A long hallway stretches out in frone of you, interrupted 
periodically by doors opening to both sides. 

To draw such a representation on the video display, we need to locate the 


viewers position and orientation within the maze, then work our way down the 


ae 





Figure 2-12 4 wireframe representation of 4 maze as seen by Someone standing in the 
middle of it 


48 


CHAPTER TWO Basic Graphic Techniques 


hallway along which he or she is currently looking. Where we find walls, we 
should draw walls. Where we find openings in the walls, we should draw 
openings. 

First, we need a variable to store the viewers current position, Well use the xy 
structure that we defined a moment ago to declare a variable called pos: 
struct xy pos={1,3}; 


This indicates that che viewer is standing at coordinate position 1,3 within the 
maze, one square from the left edge and three squares from the right edge, 

We'll also need a way to define the viewers orientation — that is, whether the 
viewer is facing in the positive x direction (toward higher x coordinate positions 
in the maze), the negative x direction (toward lower x coordinates in the maze), 
the positive y direction, or the negative y direction. Well arbitrarily refer to the 
pasitive x direction as direction 0, the positive y direction as direction 1, rhe 
negative x direction as direction 2, and the negative y direction as direction 3 (see 
Figure 2-13). That way, we can store the direction as an integer variable: 


int direction=1; 


But how will we tell the computer what these directions mean? We'll create an 
array of type xy which will hold the increments for each of these directions — 
that is, an x value of | for the positive x direction, an x value of -] for the 
negative x direction, and so forth. Well call this array mcrement and we'll declare 
it like this: 
struct xy incrementl4J=({{-1,0),{0,1},11,0},10,-1}); 


There 1s one element of this array for each of the four positions in which the 
viewer can face. Restricting the viewer's orientation to these four positions 


| (North) 





3 (South) 


Figure 2-13 The four compass directions 
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simplihes the problem of drawing the maze, since we only have to draw ir from 
these four positions. (Most of the early maze games worked this way.) Later, we'll 
learn how to draw a maze from any arbitrary orientation. 

For reasons that well see in a moment, we'll also need a pair of artays to give 
us the increments along the x and y axes for paths th rough the maze that move to 
the left and right of the viewers current orientation, We'll call these arrays left 
and right: 
struct xy Left(4]={{0,-1},{-1,0},{0,13,{1,03}; 
struct xy right(4J={{0,1},{1,0},{0,-1},{-1,03); 


We could draw the image of the maze to fll the entire display, but we'll rarely, 
if ever, need to do that in practice. Usually, we'll be drawing the maze in a 
window filing part of the display and placing other information in the remaining 
space. So lets draw a small box on the display to delineate the window in which 
the maze will be drawn: 
void drawbox(char *screen) 
{ 

Linedraw(é2,19,294,19,15,scereen); 

Linedraw(294,19,294,119,15,screen); 


Linedraw{294,119,82,119,15,screen): 
Linedraw(82,119,82,19,15,screen) > 


This short function, called arawbax(), uses the redraw) function that we 
developed earlier to draw a box on the display with its upper-left corner at 
coordinates 82,19 and its lower-right corner at coordinates 294,119 (see Figure 
2-14). 








Figure 2-14 The box drawn on the display by the DRAWBORX() 
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To draw the maze itself, we need to know how many squares the viewer is able 
to see into the distance. We'll arbitrarily choose a value of 4, which we'll store in 
the integer variable wvestbrlity: 
int visibility=4; 


Now well need to draw each of the four squares visible along the viewer's line 
of sight. Well step through all four squares using a_fer() loop: 


for(int dist=0; dist<visibility; dist++) 4 


We'll use a separate drawing routine for each of these four squares, to take the 
changing perspective into account. (We could also use a single drawing routine in 
| loop and calculate the differences in perspective on the fly, but for reasons of 
clarity well go with the former approach.) First we need to calculate the 
coordinates of the square, or block, in which the viewer is currently standing and 
the coordinates of the blocks to the immediate left and right of that block. We'll 
do this with the aid of the /eff, night, and increment arrays: 


ff Find current square of maze: 


block.x=pos.x+dist*incrementCdirection].x; 
block. y=pos. ytdist*incrementlCdirectionl.y; 


/f Find square to the left of current square: 


Lblock.x=block.x+leftlLdirectionl.x; 
LblLock.y=block.y+tleftEdirection].y; 


ff Find square to the right of current square: 


rblock.x=block.x+rightCdirectionl.x; 
rblock.y=block.y+rightCdirectionl.y; 


We'll use a suvtch statement to choose among the four different drawing 
functions: 


switch(dist) f 


For the current square, which is treated by the program as the square at a 
distance of 0 from the viewers position, we ll check to see if the square to the left 
is open or closed. If closed, we'll draw a wall on the left side of the view window, 
lf open, well draw a door: 


if (mazellblock.xIJElblock.yJ) 4 
Linedraw(82,19,135,44,15,screen): 
Linedraw(155,44,135,93,15,screen); 
Linedraw(135,93,82,118,15,screen); 

} 
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else { // Else draw opening 
Linedraw(82,44,155,44,15,screen)}: 
Linedraw(135,44,1355,93,15,screen): 
Linedraw(135,93,82,935,15,screen); 
} 





Then we'll do the same thing with the square on the right: 


// Is walk open to the right? 

ff If not, draw wall 

if (mazeCrblock.xJErblock.yJ]) f 
Linedraw(294,19,242,44,15,screen); 
Linedraw(242,44,242,93,15,scereen); 
Linedraw(294,118,242,935,15,screen); 

} 

else { // Else draw opening 
Linedraw(294 44,242 ,44,15,screen) ; 
Linedraw(242,44,242,93,15,screen); 
Linedraw(242,95,294,93,15,screen); 

} 


For the next square — the square at a distance ot 1 in the viewing direction — 
we first need to check to see if the square itself is open or closed. If closed, we 
draw a wall in the middle of the viewing window: 


ff Can we see the next square? 
ff If not, draw wall 
if (mazeCblock.xJ[block.ylJ) ¢ 
Linedraw(135,44,135,93,15,screen); 
Linedrawl242,44,242,935,15,5screen); 
Linedraw(135,44,24¢,44,15,s5creen) 
Linedraw(135,93,242,93,15,screen): 
} 


If it's open, then we do the same thing with the next square as we did with the 
current one: Draw a wall on each side if the left and/or right squares are closed or 
an opening if those squares are open, with the coordinates adjusted for 
perspective: 


else { // Else draw sides of next square 

if (mazeClblock.xJClblock.yJ) f 
Linedraw(135,44,162,57,15,screen); 
Linedraw(162,57,162,80,15,screen); 
Linedraw(162,80,135,93,15,screen); 

} 

else f 
Linedraw(135,5/7,162,57,15,screen) ; 
Linedraw(162,57,162,80,15,screen); 
Linedraw(162,80,155,80,15,screen); 
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if (maze[rblock.xJErblock.yJ) f 
Linedraw(242,44,215,57,15,screen): 
Linedraw(215,57,215,80,15,screen); 
Linedraw(215,80,242,93,15,screen); 

} 

else { 

Linedraw (242,97 ,215,9/,15,s5c¢reen); 
Linedraw(215,57,¢215,80,15,screen); 
Linedraw(215,80,242,80,15,screen); 

} 

} 

We then repeat this process for the nwo remaining visible squares, adjusting 
the line coordinates again for perspective, If the view of any of these squares is 
blocked by a wall, well want to short circuit the drawing of the maze, so we place 
a Statement at the end af the loop co watch for this situation and CXCCuULe a break 
instruction if it is encountered: 


if (mazeCblock.xJ€block.yJ) break; 


What happens if the viewer is standing within four squares of the edge of the 
maze and is looking toward the edge? How do we keep from extending our line 
of sight off the edge of the maze array? If you go back and look at the 
initialization statement for the maze array, youll see that the maze is entirely 
bordered by walls; it's not possible to see past the edge. If you should alter the 
maze array so that there are holes in this wall, what would you see through them? 
Random pieces of maze, probably, generated by junk in the computer's memory. 

There's one situation that this maze-drawing program cant handle. If four 
Maze squares arranged ina SQ UAC pattern relative [oa one another are lett Cmpty, 
there will be odd-looking gaps in the drawing. (This would be equivalent to two 
consecutive openings off the same side of the hallway leading away in the viewers 
line of sight.) Just as weve designed the maze so that its impossible to see past 
the edge, we ve also designed It +O} thar four CMply MjUdares Never appcar together 
arranged in a square. Later, well write maze-drawing routines that can handle 
this situation. 

The complete maze-drawing program is shown in Listing 2-9. 





Listing 2-9 The MAZE.CPP program 


‘/ MAZE.CPP Version 1.0 

‘/ Draw a single view inside a 3D wireframe maze 

ii 

ff Written by Christopher Lampton 

‘i for Gardens of Imagination (Waite Group Press) 
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cOninied Pram previous page 
Hinclude <stdio.h> 
finclude <dos.h> 
finclude <conio.h> 
Finclude <stdlib.h> 
Hinclude "screen.h" 
Ainclude "bresn.h" 


char mazell6é10161=¢ 
{1,141,404 ,151461 1A it 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}, 
{1,0,1,0,1,1,1,0,0,0,0,0,1,1,0,11, 
{1,0,1,0,1,0;1,0,1,1,1,0,1,1,0,1}, 
{1,0,1,0,1,0,1,0,0,0,1,0,0,4,0,13, 
{1,01 1,1,0,1,0,1,0;4,1,1,1,0,11, 
{1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,17, 
i1,0,1,1,1,0,1,0,1,1,1,0,1,1,0,11, 
{1,0,1,0,0,0,1,1,0,0,1,0,1,1,0,1}, 
{1.,0,1,0,1,0,1,1,1,1,1,8,1,1,0,13, 
{1,0,1,0,1,0,0,0,0,0,0,0,0,0,0,17, 
i1,0,1,1,1,0,1,0,1,0,1,1,1,1,0,1}, 
{1,0,0,0,1,0,1,0,1,0,0,0,0,1,0,1}, 
£1,0,1,1,1,0,1,1,1,1,1,1,1,1,0,11, 
£1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
Velelele dele lel ele lel ell), 1,13 

I; 

typedef struct xy f{ 
int X,¥; 

J; 


struct xy increment(4J={{-1,0},10,1},{1,0},{0,-13}; 
struct xy left€4J={{0,-13,1-1,0)},{0,13,11,03}; 
struct xy rightl4J={{0,13,(1,0} ,{0,-1},1-1,07}; 
struct xy pos={1,3}; 


int direction=1; 
int visibility=4; 


void drawmaze(char *); 
void drawbox(char *); 


void main(void) 
{ 


if Create pointer to video memory: 
char far *“screen=(char far *)MK_FP(Oxa000,0)> 


ff Save previous video mode: 
int oldmode=*Cint *)MK_FP(Ox40,0x49); 


ff Put display in mode 13h: 
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setmode(Ox13); 


if Clear display: 
cls(screen}; 


‘/ Draw window on display: 
drawbox(screen): 


f/f Draw the maze: 
drawmare(screen); 


ff Wait for user to hit a key: 
while ('!kbhit()); 


ff Restore old video mode: 
setmodetoaldmode) - 
} 


void drawbox(char “screen) 

{ 
Linedraw(é2,19,294,19,15,screen) ; 
Linedraw(294,179,294,119,15,screen); 
Linedraw(294,1719,82,119,15,screen); 
Linedraw(82,119,82,19,15,screen); 

} 


void drawmaze(char *screen) 


// Draw the maze stored in array mazel] into video 
‘/ memory at address screen. 


{ 
struct xy block,Lblock,rblock; 
int oldleft,oldright; 


‘/ Draw the maze at each distance allowed by visibility 
for(int dist=0; dist<visibility; dist++) 


// Find current square of maze: 
block. x=pos.xtdist*incrementCdirection].«; 
block. y=pos.y+dist*incrementldirectiond.y; 


ff Find square to the Left of current square: 
lblLock.x=block.x+LeftCdirectiond.x; 
lbLock.y=block.y+leftldirectionl.y; 


‘/ Find square to the right of current square: 
rblock.x=block.x+rightCdirection].x; 
rblock.y=block.y+rightLdirectionl.y; 


‘*f Draw image of squares according to distance: 
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Cuninned Prom prerrons pane 
sWitch(dist) f{ 
case O: // Draw current square 


ff Is wall open to the Left? 

‘f- 1f not, draw wall 

if (mazellblock.xJ€lblock.yJ) f 
Linedraw(é2,19,135,44,15,screen) ; 
Linedraw(135,44,155,93,15,screen); 
Linedraw(135,93,82,118,15,screen); 

} 

else { // Else draw opening 
Linedraw(82,44,135,44,15,screen); 
Linedraw(135,44,135,93,15,screen); 
Linedraw(135,93,82,93,15,screen); 

} 


if Is wall open to the right? 

// If not, draw wall 

if (mazeCrblock.xJErblock.yJ) f 
Linedraw(294,19,242 ,44,15,screen); 
Linedraw(242,44,242,93,15,screen): 
Linedraw(294,118,242,93,15,screen); 

} 

else { // Else draw opening 
Linedraw(294,44,242,44,15,s5creen): 
Linedraw(242,44,242,93,15,screen): 
Linedraw(242,93,294,93,15,screen): 

} 

break; 

case 1: // Repeat for next square 


// Can we see the next square? 
‘f If not, draw wall 
if (mazeCblock.xJCblock.y]) ¢ 
Linedraw(135,44,1755,93,15,screen); 
Linedraw(242,44,242,93,15,s5creen): 
Linedraw(155,44,242,44,15,s5¢reen); 
Linedraw(155,93,242,95,15,screen); 
} 
else { // Else draw sides of next square 
if (mazeClblock.xI0[lblock.yJ) f 
Linedraw(155,44,162,57,15,screen) 
Linedraw(162,57,162,80,15,screen); 
Linedraw(162,80,135,93,15,screen) ; 
} 
else f{ 
Linedraw(135,57,162,57,15,screen) : 
Linedraw(162,57,162,80,15,screen); 
Linedraw(162,80,155,80,15,screen); 
} 
if (mazeCrblock.xJCrblock.yJ) { 
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Linedraw(242,44,215,57,15,screen); 
Linedraw(215,57,215,80,15,screen); 
Linedraw(215,80,242,93,15,screen); 
} 
else f 
Linédraw(?42¢,57,215,9",15,S5¢reen); 
Linedraw(215,57,215,80,15,screen); 
Linedraw(215,80,2¢42,80,15,screen); 
} 
} 
break; 
case 2: // Do it again 
if (mazeCblock.sJCblock.yJ) f{ 
Linedraw(162,57,162,80,15,screen); 
Linedraw(215,57,215,80,15,s¢reen): 
Linedraw(162,5/,¢15,2f,15,screen); 
Linedraw(162,80,215,80,15,screen); 
} 
else 7 
if (mazeClblock.xJClblock.y]) f 
Linedraw(162,57,1/75,635,15,5creen); 
Linedraw(1/75,635,175,f4,15,scereen?); 
Linedraw(175,74,162,80,15, screen); 
} 
else ¢ 
Linedraw(162,63,175,63,15,screen); 
Linedraw(175,65,175,74,15,screen); 
Linedraw(1/5,/4,162,'°4,15,screen); 
} 
if (maze(rblock.xJ€rblock.y]) f 
Linedraw(215,5/7,2¢02,64,15,screen); 
Linedraw(202,63,202,74,15,screen); 
Linedraw(202,74,215,80,15,screen); 
} 
else f 
Linedraw(215,63,202,63,15,screen); 
Linedraw(202,63,202,74,15,screen): 
Linedraw(20?2,74,215,74,15,screen); 
} 
} 
break; 
case 3: // And again 
if (mazeLblock.xJ[block.yJ) f 
Linedraw(1/75,635,175,74,15,screen); 
Linedraw( 202 ,63,202,74,15,screen); 
Linedraw(1/5,643,202,65,15,s¢reen) ; 
Linedraw(175,74,202,74,15,screen): 
} 
else { 
if (mazeClblock.xJClblock.yJ) f 
Linedraw(1/5,63,182,66,15,screen): 
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i omtineend froin prety Pug Pe 
Linedraw( 182,66, 162,/f0,15,screen): 
Linedraw(182,70,175,74,15,sereen) : 

} 

else i 
Linedraw(1/5,66,182,66,15,screen): 
Linedraw(182,66,182,70,15,screen); 
Linedraw(182,/70,175,/70,15,screen); 

} 

Tf Cmazelrblock.xJ[rblock.yJ) f 
Linedraw(202,635,195,46,15,screen); 
Linedraw(195,66,195,70,15,screen); 
Linedraw(195,70,202,74,15,screen): 

I 

else 4 
Linedraw(202,66,1795,66,15,screen); 
Linedraw(195,66,195,70,15,screen): 
Linedraw(195,70,202,70,15,screen); 

} 

} 
break; 
} 


‘/ If view 75 obscured by wall, stop drawing: 


if (mazelblock.xJCblock.yJ?) break; 
} 
} 

Run it and — vera’ — a three-dimensional wireframe view of a maze will be 
drawn on the computer display (see Figure 2-15). Change the viewer position 
and orientation (in the variables pos and direction) and recompile to see the maze 
from other positions. (Be careful about putting the viewer inside a closed square, 
however, since the program never checks for this possibiliry:} 





Figure 2-15 [he three-dimensional maze view drawn Oy tne 
WAZE CPP program 
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While it’s all well and good to draw an image of a maze as it appears from a 
single position, as we have done here, a true maze program should be animated. 
The user should be able to explore the maze rather than sit in a single spot inside 
it. In the next chapter well look at ways in which the user can interact with our 
maze-drawing code — and then we'll create a version of our wireframe maze- 
drawing program thar will allow the viewer to explore an animated maze using 
the keyboard, mouse, or joystick. 
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raphics are an important part of what makes a computer game 
function, but they arent the only part. You also need a way to 
control or interact with the game, so that you can move 
characters around, fly spaceships, bash evil wizards, shoot 
monsters, and otherwise take our your aggressive instincts on 
innocent pixels, [f there were no way to interact with the game, you might as well 





turn off the computer and turn on the TV. 

The maze-drawing code that we developed tn the last chapter could be used as 
the core of a computer game in the mold of the early Wizardry CRPGs, But to 
make thar game interactive, we need to give the player a way to communicate 
with the computer. 

There are three major input devices used in computer games. Nor 
coincidentally, nwo of these are also the major input devices used in all PC 
applications: the keyboard and the mouse. The third, the analog joystick, is used 
almost exclusively for games. Let's look at cach of these devices in turn, starting 


with the keyboard. 


The PC Keyboard 


The keyboard is the most familiar of all input devices, for the simple reason chat 
there's Oc attached co every COMPUTer. Only SOME LISers of the TLC that Wwe 
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develop in this book will have joysticks. Quite a few will have mice. Bur each and 
every one will have a keyboard. That makes the keyboard the most important 
input device you can learn to program. It wont necessarily be the best device for 
the task at hand; in many cases, a game will be more easily controlled via the 
joystick or the mouse. But its pretty much obligatory for game programmers to 
support the ubiquitous keyboard, because its the one input device you can be 
SUITE that VOU USCIS will have, 

That may sound like good news. Surely the keyboard is easier to program than 
such relatively esoteric devices as joysticks and mice, The libraries that came with 
your C/C++ compiler are filled with functions for working with the keyboard. 
You can use these functions to cobble together a quick and dirty keyboard 
interface, then turn to the real work of programming the mouse and the joystick. 
You could, for instance, use the &brr() function to determine if a key has been 
pressed and the getch/) function to learn which key it was. Alternatively, you 
could call che INT 16h functions from the ROM BIOS if you need an even 
lower- level method of monitoring the keyboard. 

Alas, things arent quite that simple. The PC keyboard is a strange and 
complicated thing. It can do some nifty tricks for the programmer who knows 
how to make it strut its stuff, but the keyboard functions that are supplied with 
most compilers don't support the type of keyboard input that most games require, 
Neither do the keyboard routines built into the PC's ROM BIOS. In fact, if were 
going to provide proper keyboard input for our maze games, we really have no 
choice bur to write our own low-level machine language input functions. 


Two Keys ata Time 


Perhaps the single greatest dehciency of the keyboard routines that come bundled 
with the compiler and the ones that are built into the ROM BIOS ts thar they 
dont allow us to detect when two keys are being pressed at the same time. For 
most nongame applications (with the exception of terminate-and-stay-resident 
utilities, which are a whole different ball of wax), this isnt particularly important. 
Programmers developing word processors, for instance, usually only care about 
the order in which keys are pressed, so detecting the simultaneous pressing of two 
keys Is largely irrelevant to them. 

Game programmers, by contrast, are in constant need of this information. 
Suppose, for instance, that we want to allow the user of our maze games to move 
forward through the maze by pressing the () key while firing bursts from a laser 
eun by pressing the . If we could only detect the pressing of one key 
at a time, it would be necessary for the player to stop moving every time he or 
she needed to fire the weapon, a requirement that would hardly endear most 
players CO OUT Palme, 
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Luckily for us, its quite possible to detect the simultaneous pressing of two 
keys on the PC keyboard — if we write our own low-level keyboard code. But 
low-level keyboard code ts notoriously tricky to write, because it involves entering 
the shadowy and mysterious world of interrupt service programming. If youre 
the sort of programmer who can write three UNIA-compatible operating systems 
before breakfast, this will be old stuff to you. The rest of you, however, should sit 
up and pay close attention. 


The Keyboard Interrupt 


The secret of programming the PC keyboard is realizing that the keyboard is a 
computer in its own right, More precisely, it contains within it a special purpose 
microprocessor called an Intel 8042 or 8048, depending on what generation of 
PC you happen to be programming. (Because the 8042 or a compatible processor 
is used in the keyboards of later PCs, we'll use thar number to refer to the 
keyboard processor in this text.) The 8042 monitors the pressing of keys on the 
keyboard and sends an electronic report back to the computers main CPU every 
time a key is pressed. (It also sends back a report when a key ts released, which 
allows us to detect the simultaneous pressing of two keys. More about that in a 
few pages.) To find out whats happening on the keyboard while our program ts 
running, we must learn to talk with the 8042 processor — or, rather, how to 
make it talk to us. 

When a key is pressed on the keyboard, the 8042 sends a signal called an 
interrupt to the computers CPU. An interrupt ts a signal that causes the computer 
to quit what its doing and execute a special subroutine called an interrupt handler. 
There are a number of different interrupts that can occur in the course of a PC's 
daily operations, This particular interrupt is known as the keyboard interrupt. 
(Officially, the keyboard interrupt is designated as interrupt 09H.) 

There is a standard keyboard interrupt handler routine built into the ROM 
BIOS that came with your computer. Ordinarily, it is this routine that is executed 
when a key is pressed on your keyboard. When executed, this routine sends a 
message to the 8042 processor requesting an identifying number, called a scan 
code, for the last key pressed. The scan code identihes the physical key that has 
been pressed. There are 101 keys on most PC keyboards and the 8042 uses a 
unique scan code to identify each one of them. It's important to realize that the 
8042 can identify keys only by scan code. It has no idea what symbols, such as 
letters of the alphabet or puncruation marks, the keys represent. When the BIOS 
keyboard interrupt handler receives a scan code from the 8042, it consults a 
symbol table to determine what symbol is represented by that key. (This table can 
easily be altered, incidentally, allowing users to reprogram the keys on the 
keyboard to represent any symbols in the standard IBM character set. Thus a user 
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who is tired of the QWERTY keyboard and wants to experiment with a Dvorak 
keyboard can easily do so by running a simple program, though the letters 
emblazoned on the keycaps will remain unchanged.) 

After receiving the scan code from the 8042, the BIOS keyboard interrupt 
handler stores it in an array called the keyboard buffer. Then, when an 
application program calls the INT 16h functions in the ROM BIOS to find out 
which key was last pressed, the BIOS removes the scan code from the buffer and 
returns it to the program, along with the ASCII code for rhe symbol that is 
represented by that key. For example, if the last key pressed was (@), the 
keyboard routine will return the scan code 30, which is the scan code for the key 
that ordinarily has the letter “A” on top of it, along with the ASCII code 97, 
which is the code for the lowercase letter “a.” (If the key was pressed 
simultaneously with the *a® key, the ASCII! code for an uppercase letter “A” will 
be returned instead, Although I said earlier that the BIOS routines could not tell 
us about the simultaneous pressing of two keys, the key is an exception to 
this rule.) 

The keyboard buffer can hold 15 scan codes, Should it fill up before an 
application program asks the BIOS to remove these codes, the keyboard interrupt 
handler will refuse to place additional scan codes in the buffer and will cause the 
PC speaker to emit an obnoxious beeping noise every time the user presses a key. 
If youve used a PC for more than ten minutes, you've probably heard this noise 
several dozen times. A side benefit of writing your own keyboard handler is that 
the users of the games you write will never, ever have to listen to that noise while 
playing them! 


SWIpIng the Interrupt 
Before we can write our own keyboard handler, we'll need a way to steal the 
keyboard interrupt away from the BIOS routine that's already handling it. 
Fortunately, this is simple to do. Theres a routine in the ROM BIOS thar allows 
us to install our own interrupt handlers, replacing if necessary the ones that are 
already present in the BIOS. We can call this routine to install our custom 
keyboard handler during the initialization phase of our game, then call it again 
when the program ends to put the old keyboard handler back in place. (The users 
of the game would be less than thrilled if they returned to DOS only to discover 
that our keyboard handler was still running — especially when they tried to type 
a command at the C> prompt and nothing appeared on the display.) 

Our collection of low-level keyboard handler routines will consist of three 
assembly language functions: one to install the new keyboard handler, one to 
remove it, and the keyboard handler itself. We'll call these functions initkey(), 
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assembly language. (Technically, mewkep() isnt actually a function, since well 
never call it directly from C/C++. It will be called automatically when a keyboard 
interrupt is generated — that is, when the user presses a key.) We'll place these 
three functions in an assembly language module called [O.ASM, along with the 
other low-level input functions that we'll develop in this chapter. 


The initkeyQ Function 
The BIOS routine thar installs a new interrupt handler is one of a large set of 
routines in the PC ROM known as the INT 21H routines, after the assembly 
language instruction that is used to call them. Specifically, it is function 25h, 
otherwise known as Set Interrupt Vector. Before we can call this function, 
however, we must call function 35h, also known as Get Interrupt Vector, to learn 
the number of the old keyboard handler routine — so that we can restore it when 
the program terminates. And to store the address of the old function, we'll need 
to set aside 16 bits of memory for the segment and 16 bits for the offset. 

The last of those tasks is the easiest. In assembly language, we can allocate 16- 
bit data storage with the DW (Define Word) directive, like this: 


intofs dw 0 
intseg dw O 

These two DW directives allocate a pair of 16-bit storage locations (equivalent 
to inf variables in C/C++) called imtoft and imtseg. Well use the first to store the 
offset of the old interrupt vector and the second to hold the segment, We'll also 
need a memory location for storing information about which keys are being 
pressed. This location will need to be accessible to both our C/C++ routines and 
the keyboard handler, so we'll define it in C++ as an array and pass its address to the 
tnitkey() function, which will store this address where it can be accessed by the 
newkey() handler, We'll define storage for the address of this array the same way 
WE assigned storage for the address of the old Interrupt handler: 


bufseg dw 0 
bufofs dw O 


The first of these will hold the segment of the array, the second the offset. The 
actual form that this array will take will be explained in a moment, when we 
discuss the keyboard handler function. 

Next, well call INT 21h function 35h using the same procedure we 
demonstrated for calling DOS and BIOS functions in the last chapter: 
mov ah,35h s Call INT 2th Function 35h 


mov al,O9h } «..to get current address of 
int 2th : ...interrupt OPh 
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The 35h placed in the AH register is the number of the function that will give us 
the address of the old interrupt handler; the 09h in AL is the number of the 
function that the handler handles. On return from this call to DOS, the BX and 
ES registers will contain the offset and segment of the old interrupt handler, 
respectively. We can move these values directly into the storage locations we ve set 
aside for them: 

mov intseg,es ; save Segment 

may intofs,bx ; «sand offset 


To install a new interrupt handler, we must place the segment and address of the 
new handler in the DS and DX registers, then call INT 21h function 25h: 

mov dx,seg _newkey ; Put the segment of new 

moy ds,dx : ...interrupt handler in DS 

mov dx,offset newkey ; Plus offset in Dx 

mov ah,25h ; Call INT 21th Function 25h 

' 


mov al,O9h -+.tQ install new handler 
int 3 2th 


Finally, we'll take the address of the bufter in which key data will be passed 
back co our C/C++ program and store it in the locations we set aside for it earlier. 
The address will have been passed to the imthep() Function in a 32-bit parameter 
called buffer, so well move the segment portion and address portion of that 
parameter into storage: 
les dx,buffer ; Save address of new scan code buffer 


mov butseg,es 
mov  bufofs,dx 


And then we'll recurn co C++. The complete taiekey() function is in Listing 3-1. 





i Listing 3-1 The initkey0 function 


_initkey PROC 
; Initialize keyboard interrupt handler 
ARG buffer: DWORD ; Pointer to scan code buffer 


push bp ; Save BP register 

mov bp,sp 

push es : Save ES and 0S registers 
push ds 

mov ah,35h : Call INT 27h Function 35h 
moy al,09h * ...tO get current address of 
int 21h ; aeeinterrupt OFh 

mov iintseg,es ; Save segment 

mov intofs,bx ; ««.8nd offset 

mov dx,seg _newkey ; Put the segment of new 
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mov ds,dx : ws. interrupt handler in BS 

mov dx, ,offset _newkey ; Plus offset in DF 

mov  ah,25h : Call INT 21h Function 25h 

mov aLl,O9h ; ...to install new handler 

int ih 

Les dx,buffer ; Save address of mew scan code buffer 


mov butseg,es 
mov butfofs,dx 


pop ds , Restore registers 
pop es 

pop bp 

ret 


_initkey ENDP 


The remkey() Function 


The reméey() function, which removes the new keyboard handler and reinstalls 
the old one, is extremely simple. It loads the offset and segment of the old 
handler into DX and DS and calls INT 21h function 25h again. Aside from the 
usual set-up and return instructions, thats all it does. The complete function 
appears in Listing 3-2. 





Listing 3-2 The remkey0 function 


_remkey PROC 


push ds , save DS register 

mov dx,intseg ; Get segment and offset of 
mov ds,dx ; «2s0ld interrupt handler 
mov dx,intots 

mov ah,25h * Call INT @1h Function 25h 
mov al,O?h ; ws. to restore old handler 
int) 2th 

pop ds ; Restore DS register 

ret 


_remkey ENDP 


The newkey() Function 


The most important of the three low-level keyboard functions is the newkey() 
function, This is the actual interrupt handler that we installed and removed with 
the last wo functions. It’s written pretty much like any other assembly language 
procedure, except that (1) we cant pass any parameters to tt (because well never 
actually call it), (2) we must end it with an IRET (Interrupt RETurn) instruction, 
and (3) we must be careful to save the value of every CPU register that we use in 
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the course of the procedure, The reason for this last requirement is that an 
interrupt handler such as this will be executed at unexpected times, while the 
computer is performing other tasks. We must be careful not to mess up the values 
stored in the registers lest we interfere with whatever task is in progress when the 
user presses a key. We must leave all registers precisely the way we find them. 
Once weve finished saving the registers, however, we can get down to the 
serious business of handling the interrupt. First, we need to get the address of the 
buffer that we passed from C++ earlier and put it into a register (or, rather, pair 
of registers), This butter is a 128-byte array of type char in which each position 
corresponds to one of the 1()1 scan codes that can be returned from the PC 101- 
key keyboard. (See Figure 3-1 for a chart showing which scan codes represent 
which keys.) Of course, since the keyboard has 101 keys and the array has 128 
elements, that leaves a few unused Spacers in the butter, But we Il leave those Extra 
27 entries in place for future keyboard expansion (and so that we wont 
accidentally trash memory beyond the end of the array should the keyboard 
processor accidentally send us nonsense data). The design of the PC keyboard is 
such that it can never have more than 128 scan codes, so we should be safe into 
the foreseeable future. We'll put the segment and offset of the buffer into registers 
ES and DI, where we can use them as a pointer to the start of the array: 
mov ax,bufseg ; Point ES:DBI at sean code buffer 


mov €5,ax 
mov di,bufofs 


Next, we'll get the scan code for the last key pressed from the keyboard 
processor. [his is done by inputting data through data port 60h. (See Appendix B 
on machine language programming for more detail on inputting data through 
ports.) Well input the data to register AL: 
in al,6O0h ; Get the latest scan code 


In a moment we're going to use the 1G-bit value in the AX register as an index 
into the scan code buffer, based on the value that we just input to the AL register. 
Since AL is already part of the AX register — see Appendix B for details — the 
job of setting up the index is half done, but we'll need to put a 0 in the other half 
of the register, like this: 


mov ah,O ; cero high byte of Ax 


The scan code is now in the AL register, This code will be either a make code 
ora break code — that is, it will either indicate that the key corresponding to the 
code has just been pressed or that it has just been released, How can we tell the 
difference? A break code is equal to the scan code for the key plus 128, while a 
make code is equal simply to the scan code. Since no scan code on the PC 
keyboard is allowed to have a value greater than 127 (and at present none have 
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Key Code Key Code Key Code 
Esc | A 30 Copslock 58 
a th oe 5 3] Fl 59 
Mo? 3 0 a2 F? 60 
#ood 4 F 33 FS 6] 
Sad 45 6 34 FA 62 
Ros 4 H 35 F5 63 
‘oh 7 J 36 Fé 64 
Eo 68 K 37 F] 65 
* oh 9 l 38 FA 6b 
( or? 10 \ Geeks Soe FY 67 
) ao 1 Tl re 4) FIO 68 
_ O- 1? -~ 7 4] FI 193 

= 3 lef Shift 42 FI? 134 
Bksp 14 loa Numbock 69 
Tob 15 44 Scroll Lock «= 70 
0 16 i 45 Homeor? = 7 
W 17 ( 46 Up or 8 rei 
E 18 V 4] PoUpor? 73 
R 19 Q 4§ Gray - i4 
T 20 N 49 leftord 75 
Y 7 Mi 40 Centeror5 76 
U 22 ey ae Rightorb = 77 
23 > oF. 92 Gray + i 
0 74 ’ of 53 End or | 19 
P 25 Right Shift == 54 Downor? 80 
{ wit & PriScor® = 55 Podnord = BI 
Eco oF Alt 56 Ing or 0 A? 
Enter 28 Spocebor 57 Del or , a3 
Cir 29 


Figure 5-1 The scan codes for the 101-key keyboard 


values greater than 108), this means that make codes have values in the range 0 
ro 127, and break codes have values in the range 128 to 255. 

The next thing that our keyboard handler must do, then, is to check to see 
which kind of code it has received. We'll use the CMP (compare) instruction to 
compare the value in AL with 128: 


cmp al,126 > Was code a "make" or a “break"? 


If its a break code (that is, if a key has been released), this instruction will set 
the CPU borrow flag (see Appendix B). We can make a jump instruction 


= Tes i 


| : y= ll 
a = 
a. E = 


= 
| 
& = 
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contingent on this Hag and branch to the routine for handling break codes if the 
Hag is set: 


inb break ; If break, skip ahead 


If this jump isnt taken, then irs a make code — that is, a key has been 
pressed. Well move the value in AX to BP where we can use it as an index into 
the buffer, And we'll store a 1 in the buffer element corresponding to this scan 
code, to indicate that the key is currently pressed: 


mov bp,ax 7; Else use code as index into buffer 
mov Cbyte ptr es:di+bp],)] ; And flag key as pressed 
imp endkey 


That last instruction skips aver the instructions that handle break codes. These 
instructions are just like those that handle the make code, except that they first 
subtract 128 from the scan code (by ANDing the value with 127; see Appendix 
B) and then move a 0 into the appropriate buffer position rather than a 1: 


break: 
and = al,1le? ; If break code, remove high bit 
mov bp,ax ; Use code as index into buffer 


mov Cbyte ptr es:di+tbp],0 ; Flag key as released 


The next four instructions, which are performed whether or not the code was 
a make or a break, change the value of a single binary digit of the value received 
through input port 6lh, then send this value back out through that port. This 
rather odd operation “clears” the interrupt request — that is, it tells the 6042 
processor in the keyboard that we won't be needing further copies of the most 
recently received scan code, (It's possible to write keyboard handler routines that 
“chain” to the regular BIOS keyboard handler by not clearing the interrupt 
request and passing control to the regular handler once the custom handler does 
its thing. This, for instance, is the method that terminate-and-stay-resident 
utilities — TSRs — use to watch for the pressing of certain key combinations 
while not disturbing the activity of the regular keyboard handler.) 

Here's how the clearing operation is performed: 
endkey: 

in «ai, 6th ; Clear the keyboard interrupt 

mov ah,al 

or al,80h 

out 41h,al 

We must also send a message to the PC's general interrupt handling circuitry, 
which up until now has been refraining from sending any additional interrupts to 
the CPU while we performed our interrupt processing, telling it that the 
computer is ready to process other interrupts. This is done by sending a value of 
20h through output port 20h: 
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al,¢Oh 
?0h,al 


mov : Allow additional interrupts 


out 

The rest of the Interrupt handler consists of restoring the value of all saved 
registers and executing an IRET instruction. The complete text of the keyboard 
interrupt handler appears in Listing 3-3. 





Listing 3-3 The newkey0 function 


_newkey PROC FAR 
push ax - Save all registers used 
push di 
push bp 
push es 
mov ax,butfseg - Point ES:BI at scan code buffer 
mov e5,ax 
mov di,butofs 
in al ,40h ; Get the latest scan code 
mov ah,O0 - Zero high byte of AX 
cmp 3=—soaaL , 128 - Was code a "make" or a "break"? 
jnb break - If break, skip ahead 
mov bp,ax ; Else use code as index into buffer 
mov (Cbyte ptr es:ditbpl,1 ; And flag key as pressed 
jmp  endkey 
break: 
and  al,l2? ; If Break code, remove high bit 
mov bp,ax ; Use code as index into buffer 
mov Cbhyte ptr es:ditbp],0 ; Flag key as released 
endkey: 
in =o al,é6th ; Clear the keyboard interrupt 
mov ah,al 
or al,&Oh 
out 6Th,al 
mov al,2Qh ; Allow additional interrupts 
out #20h,al 
pop eS ; Restore registers 
pop bp 
pop di 
pop ax 
iret 


_newkey ENDP 


Using the Keyboard Functions 

These three low-level keyboard functions — inrtkey(), rembey(), and newkey() — 
must always be used together. And they must be used with considerable caution. 
When our custom keyboard handler snaps into place, it will be the on/y means we 
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have of communicating with our program, Even the familiar (G7RO}(&D)-(ED) 
combination will cease to work. If you're debugging a program under Turbo 
Debugger or the built-in debugger that comes with the Borland C++ IDE, you'll 
no longer be able to terminate the program by hitting (CTRL}(Esc). So it's 
imperative that you put some kind of escape clause into your program before the 
first time you run it, even if youre working within a familiar resting and 
debugging environment. For instance, you can add code to your program that 
will watch for the keyboard handler to report that the key (scan code 1) has 
been pressed, 

Here's how you can incorporate the keyboard handler into a program. Link 
the 1O.ASM file to your code and include the [O.H header file at the top of any 
modules that reference the inrtkey() or remeey() functions. Put a call to initkey() 
near the beginning of your code, like this: 


Initkey(scanbutfer); 


where scanbuffer isa 128-byte array of type char with non-local scope — that Is, 
it has been declared externally to any functions. From that point until you invoke 
the rem&ey() functions, the scan codes of all keys pressed on the keyboard will be 
instantly (and rather mysteriously) Hageed in the seanbuffer array. For instance, if 
the key (which has a scan code of 28) is pressed, element 28 of this array 
will be set to | for as long as ir is held down. It will be reset to 0 when the key ts 
released, Your program can test these elements to see which keys are currently 


being pressed. 


The SCANKEY Program 


Now let's test our keyboard handler to see if it works as expected. The short 
program in Listing 3-4 (available on the disk as SCANKEY.EXE) will repeatedly 
print the word “ENTER” on the display as long as the (ENTER) key is being held 
down and the word “SHIFT” as long as the (HFT) key is held down. If both keys 
are pressed simultaneously, it will print both words alternately. When the (sc) 
key is pressed, it terminates. It does all of this simply by installing the keyboard 
handler and watching for elements 1, 28, and 42 (scan codes for (ES), (ENTER), and 
SHIFT)) to be ser to |. (Actually, it watches for them to be set to any non-zero 
aloe) The SCANKEY output looks like this: 

SHIFT 

SHIFT 

SHIFT 

SHIFT 

SHIFT 

SHIFT 

SHIFT 
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SHIFT 
SHIFT 
SHIFT 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 
ENTER 





Listing 3-4 The SCANKEY.CPP program 


// SCANKEY.CPP 

if 

‘/ Demonstrates alternate keyboard handler 

ii 

// Written by Christopher Lampton 

‘/ for Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 
finclude “to.h" 


char far scanbuffer(li28); // Buffer for 128 scan codes 


Vold main(void) 

{ 
‘/ Install alternate keyboard driver: 
initkey(scanbuftfer); 


‘/ Loop until ESC (scan code 1) is pressed: 
while('scanbufferlil]) f 


ff Watch for SHIFT key: 
1f (scanbufferl42]) printf("SHIFTin"'); 


// Watch for ENTER key: 
1f (scanbutferl26J]) printf("ENTER\n"); 
} 


‘f Remove alternate keyboard handler: 
remkey(): 
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Removing the Keyboard Handler 
Once youre finished with the keyboard handler, remove it by calling the reméey() 
function, like this: 


remkey()s 


Forget to do that, and the computer will appear to lock up when your 
program ends, OF course, you may not notice this if youre running under Turbo 
Debugger or the Borland IDE at the time, since both of these programs are 
aggressive about re-installing their own keyboard handlers when a program 
terminates. But most users of your program will be running it from the DOS 
prompt, where applications are expected to observe an honor system about 
reinstalling the old keyboard handler when their work is done. Later in this 
chapter, well show you how to incorporate these low-level keyboard handling 
routines into a higher-level interface, in this case an event management module 
for a wireframe maze program. For the moment, however, we're going to turn to 
another input device, the PC mouse. 


The PC Mouse 


For microcomputer users, the input device known as the mouse has always been 
more closely identihed with the Apple Macintosh computer than with the IBM 
PC and its clones, That's because the mouse has been standard equipment with 
all Macintoshes since the first Mac rolled off the assembly line more than a 
decade ago. It's pretty much impossible to use a Macintosh without one. 

PC users, by contrast, have come to the mouse in dribs and drabs. Until 
recently, most PC software used the keyboard as the primary input device, with 
mouse support added as an afterthought (if at all). But the increasing popularity 
of the Microsoft Windows operating system has changed that. Like the 
Macintosh operating system, Windows is expressly designed to be used with a 
mouse. And, as Windows has found its way onto more and more computer 
systems, so have mice. Now its a rare PC-compatible computer that doesnt have 
one attached to it. 

Game designers have taken note of this phenomenon. More and more, the 
mouse is being made available as an optional control device on PC-based games. 
Many PC games are now being designed with the mouse as a primary input 
device, though keyboard control is still made available for those users without a 
radent attached to their system unit. Dungeon Master, the seminal maze game 
mentioned in chapter |, is quite difficult to control without a mouse, This is due 
in part to its heritage on the Atari ST, a computer that (like the Macintosh) 
comes with a mouse as standard equipment, but games inspired by Dungeon 


a) 
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Master — SSI's Eye of the Beholder series, for instance — also tend to have a 
strong mouse orientation. Although a maze game can be designed without mouse 
support, it is increasingly essential that the maze game programmer have a 
background in mouse-programming skills. 


The Mouse Driver 


Youll be happy to know that we dont have to design our own low-level handler 
for the mouse the way we did for the keyboard. That's because a low-level mouse 
handler is supplied with every mouse sold. Its called the mouse driver and ts 
generally loaded into the computers memory when the CONFIG.SYS and 
AUTOEXEC.BAT files are executed at power-up time. (Some mouse drivers are 
booted from CONFIG.SYS and others from AUTOEXEC.BAT, depending on 
how the driver itself has been implemented.) To receive information from the 
Mouse, We have only City call this driver and tell it what We Want TO know, There's 
a standard interface that programs can use to talk to the mouse driver, so this is 
actually a very simple process. (Some early mouse drivers, which did not follow 
the standard for such drivers set by the Microsoft Mouse, may not respond to the 
standardized set of mouse driver commands, burt these are now fairly rare and can 
gencrally be ignored. However, you should specify thar Your PRCT aITLSs require a 
Microsoft-compatible mouse lest some user with a prehistoric driver complain 
that your program wont work on his or her machine.) 

Like the input routines in the BIOS, the mouse driver is best accessed from 
assembly language, since interfacing to the mouse driver from C++ is awkward at 
best. So we'll add a few short mouse routines to our [O.ASM fle, which can then 
be called as functions from a C/C++ program. Although these routines will barely 
scratch the surface of the tricks that the mouse can perform — theyll only call 
three of the many functions available from most mouse drivers — they will 
nonetheless provide us with enough information to allow us to use the mouse in 
Or Proeralns. | 

The mouse driver functions that we will be calling are listed in Table 3-1. 
These functions are designed to be called from an assembly language program 
using the INT 33H instruction. The number of the desired function must be 
placed in the AX register before the call. Additional information is exchanged in 
the other registers listed in the table, The first of these functions, function 0, 
simply initializes the mouse driver. (It also tells us how many buttons the mouse 
has, since some PC mice have two buttens and others have three.) Function 3 
tells us whether or not any of the three mouse buttons is being pressed. (It also 
returns a pair of numbers representing the current position of the mouse, but 
were going to ignore these in favor of the information returned by the next 
function.) Function OBh tells us how far the mouse has moved across the user's 
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desktop since the last time the function was called and in what directions it has 
moved. This relative position is measured in a unit called, for obvious reasons, 
the mickey, which is equivalent to 1/400th of an inch, (For older mice, the 
mickey ts equal to 1/200th of an inch.) 

To access these functions, well create three assembly language mouse 
functions: futmouse() to initialize the mouse interface, readmbutton() to detect 
whether the mouse button has been pressed, and relpos() to read the position of 


the mouse relative to the last position reported. 





Table 3-1 The mouse driver functions called by the routines in this chapter 
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The initmouse() Function 

The raitmouse() function mostly just loads a 0 into the AX register and calls the 
mouse driver. While it may not be obvious from looking at the function itself, it 
also returns an error code as the integer value of the function, since the mouse 
driver leaves this code in the AX register and the contents of this register are 
automatically passed back to C/C++ as the result of the function call. A 0 value 
means that an error has occurred. 

Listing 3-5 contains the text of the sntmouse() function. 





Listing 3-5 The initmousel) function 


_initmouse PROC 
: Call mouse driver initialization routine 
moy ax,0 > Request function zero (initialize) 
int 33h ; Call mouse driver 
ret ; Return with error code in AX register 
_initmouse ENDP 


The readmbuttoni) Function 


The function that returns information about the mouse buttons isnt much more 
complicated. The readmébutton() function calls mouse driver function 3, which 
reports on the absolute position of the mouse and the status of the buttons. Were 
not interested in the absolute position of the mouse, so this value is ignored. A 
single byte value describing the current status of the mouse buttons ts returned 
from function 3 in the BX registers, so we move that value into the AX register 
where it is returned to C/C++ as the integer value of this function. The first three 
individual bits — binary digits — in this 16-bit binary number tell us whether 
the equivalent mouse buttons are pressed or not. If a button is pressed, the 
equivalent bit is set co 1. If not, the bir is reset to 0. The first (or rightmost) bit of 
the number represents the Status of the lett TOUS button, the second bit 
represents the status of the right mouse button, and the third bit represents the 
status of the center mouse button, Well show you more about how to read these 
bits ina moment, The text of the readmbutton() function appears in Listing 3-6. 





Listing 3-6 The readmbutton() function 


_feadmbutton PROC 


; Read mouse button 
CPT ere OFF Fan Page 
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comer rare Rrra i Putpe 


mc ax, ; Request function 3 (read buttons) 
int 53h ; Call mouse driver 
may ax,bx ; Put result in function return 


; 0 register 
ret 
_readmbutton ENDP 


The third button isnt present on all PC mice, so you shouldnt assume that 
the user has one. Some games assign an inessential function to this button, often 
one that can also be accessed from the keyboard, but the majority of games 
ignore it completely. 


The relpos() Function 

Finally, we want to know how far the mouse has moved since the last time we 
checked up on its whereabouts. The re/pos() function obtains that information by 
calling mouse driver function Obh, The mouse can move in two directions, 
roughly corresponding to the x and y axes of a Cartesian coordinate system, so the 
mouse driver will return to us two values representing the relative position of 
the mouse in each direction, as measured in mckeys. Negative values represent 
movement to the left or up while positive values represent movements to the 
tight or down. (Note that this corresponds to the way in which Cartesian 
coordinates on the video display traditionally grow smaller to the left and up and 
larger to the right and down. See Figure 3-2.) 













Positive 
mickeys 


Figure 3-2 Negative mickeys represent 
movement up and left; positive mickeys 
represent movement down and night 
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Since the redpos() function will need to return both of these values to the 
C/C++ routine that is calling it, we'll need to pass the function pointers to a pair 
of integer variables in which it can return these values. We'll do this using the 
ARG directive, as described in the last chapter (and in the appendix on assembly 
language), After calling the mouse driver, the refpos() function will retrieve the 
two values from the CX and DX registers, place them in the variables pointed to 
by these pointers, and return to the caller. The text of the refpos() function 
appears in Listing 3-7, 





| Listing 3-7 The relpost) function 


_relpos PROC 
; Get changes in mouse position relative to last call 
ARG x:DWORD,y:DWORD 


push bp 
mov bp,sp 
mov ax,000bh ; Request function Obh 
, ‘relative mouse position) 
int 33h ; Call mouse driver 
les bx,x ; Point es:bx at x parameter 
mov LCes:bxl,cx ; .» ahd Store relative position 
les bx,y¥ ; Point es:bx at y parameter 
mov Ces:bxl,dx ; «..and store relative position 
pop bp 
ret 


_relpos ENDP 


Why would we be interested in the relatrve position of the mouse, as opposed 
to its aéselute position? In this book, we wont be using the mouse to guide a 
pointer on the display, the way that some programs do. Instead, well be using it 
much the way we use the joystick, to indicate directions of motion, Thus all we'll 
really need to know is the direction in which the mouse is moving, which can 
easily be determined from its relative position. More about this in a moment. 


Using the Mouse Functions 

To use these three mouse functions in a program, link TO.ASM to your code and 
include the [O.H file in all modules that reference them. Initialize the mouse 
during the initialization of the program by calling mrtmowse(), like this: 


if (!initmouse()) exit(1); 


Youll notice that this instruction exits the program with an error code if the 
imitmouse() function returns a 0 value. (You'll recall that this means an error 
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occurred in initializing the mouse.) Alternatively, if the mouse isn't crucial to 
your game, you could set a flag indicating that the mouse isn’t available for use, 
then continue with the program, like this: 


if Cinitmouset)) mouse _input=FALSE; 


To find out if the left or right mouse buttons are currently being pressed, call 
the readmbutton() function, like this: 


int button_status = readmbuttont) 


If the left mouse button is being pressed, the first bit — that is, the rightmost 
binary digit — of the integer variable button_starus will be set to 1. You can test 
for this by performing a bitwise AND between butten_status and the constant 
number 1, then testing the result to see if its non-zero, like chis: 


if (button_status & 1) 
printf("The Left mouse button is being pressed. \n"); 


If the right mouse button is being pressed, the second bit of button_status will be 
set to 1. You can similarly test for this by performing a birwise AND between 
button_status and the constant number 2. The predehned constants 
LMBUTTON and RMBUTTON, equal to | and 2 respectively, are provided in 
the 1O.H file for this purpose. 

Finally, to determine if the mouse has moved since you last checked, you can 
call the re/pes() function, passing pointers to a pair of integer variables to it as 
parameters, like this: 
int xrel,yrel; 
relpos(&xrel,gyrel); 


Qn return from this function, xref will contain the number of mickeys that the 
mouse has moved in the x direction since the last call to this function, with 
negative values representing movements to the left and positive values 
representing movements to the right. Similarly, yre/ will contain the number of 
mickeys that the mouse has moved in the y direction since the last call to this 
function, with negative values representing upward movements and positive 
values representing downward movements, 


The MOUSE Program 

To demonstrate the mouse functions, Listing 3-8 contains a short program called 
MOUSE.CPP. available on the disk as MOUSE.EXE, which prints the x and y 
coordinates of the mouse and the status of the mouse burtons on the text display, 
updating them continuously as you move the mouse and press the buttons, 
(Pressing the right mouse button also terminates the program, so youll only see 
the pressing of this button reported briefly before the program ends.) It does this 
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by assuming the initial position of the mouse to be at coordinates 0,0, then 
calling refpes() on every pass through a loop and adding the relative changes in 
the mouse position to these coordinates. At the same time, it calls reaambutton() 
to check for the pressing of the mouse button. The gotaxy() library function, 
prototyped in the CONIO.H header file, is used to format this information 
neatly in the middle of the text screen. (The efser(} function, prototyped in the 
same file, is used to clear the display while the program is initialized.) The MOUSE 
output looks like this: 

Mouse X 442 

Mouse Y= -279 


Left button not pressed 
Right button not pressed 





>a Listing 3-8 The MOUSE.CPP program 


ff MOUSE.CPP 

fi 

// Demonstrates mouse interface functions 

fi 

‘/ Written by Christopher Lampton 

/f for Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 

Hinclude <stdlib.h> 
finclude <conio.h> 

Finclude "“to.h" 


void main(void) 
{ 
int bstatus,xrel,yrel; 
int mousex=0,mousey=0; // Mouse x,y positions 


f/f Clear text display: 
elrser(): 


ff Initialize mouse driver: 
if (linitmouse()) exit(1); 


/*f Read mouse button status: 
bstatus=readmbutton(}; 


// Loop until right mouse button i5 pressed: 
while<'!(bstatus & RMBUTTON?)) f 


‘/ Read relative mouse position: 
COR tied en Hex par 


‘= 
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conned Prt Preis panne 


relLpos(&xrel,&yrel); 


‘i! Update mouse position variables: 
mousext=xrel ; 
mousey+=yrel ; 


‘/ Write mouse positions on display: 
gotoxy(20,10); 

printfé("Mouse X=4éd",mousex): 
gotoxy(20,11); 

printt("Mouse Y=46d" ,mousey); 


// Read mouse button status: 
bstatus=readmbuttont); 


‘/ Write button status on display 

gotoxy(20,12); 

if (bstatus & LMBUTTON) printf("Left button pressed pe bs 
else printft("Left button not pressed}: 

gotoxy(20,135)> 

if (bstatus & RMBUTTON) printf("Right button pressed a 
else printf("Right button not pressed"); 


Tne PC Joystick 


Finally, we come to the joystick. Its hard to think of the joystick as being a 
strange and obscure input device — joysticks for home gameplay have been 
around at least since the Atari 2600 game machine was released back in the 
1970s — yet its probably the hardest input device to find solid information 
about. This may be because its only used for game input and not for ‘serious’ 
purposes (though flight simulator fans, who have been known to take their 
hobby very seriously, may disagree with this summation), High-minded 
programming texts usually dont contain information on such frivolous devices as 
the joystick. 

There are a couple of joystick functions in the PC's BIOS, but they arent 
especially useful. As with the keyboard, well write our own assembly language 
joystick routines that interact directly with the joystick hardware. Well put these 
functions into [O.ASM, along with our growing array of assembly language I/O 


functions for other PC. input devices. 


Analog JOYSstICcKS 
The PC joystick is an analog joystick, This means that it can give us information 
that the joysticks attached to certain other computers, such as the Atari ST and 


O_o 
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Commodore Amiga, cannot. Not only can ir tell us whether the user is pressing 
the joystick buctons and pushing the stick up, down, right, or left — bur it can 
tell us how jar the user is pushing the joystick. Alas, this makes the joystick rather 
difficult to program. 

On an assembly language level, we can receive information about the joystick 
by inputting data through port 0201h, with a series of instructions such as this: 
mov dx,02017h ; Put gameport address in OX 


out dx,al ; Send random data through port 
in atl,dx ; Get valid data from port 


The first instruction establishes 0201h as the number of the port we wish to send 
data through. The second instruction outputs random data through the port, 
which signals to the joystick circuitry that we wish to receive information about 
the stick position. And the third instruction receives data from the joystick and 
places it in register AL. 

The value that we receive from the joystick with these instructions is known as 
the gameport byte. The individual bits in the gameport byte give us information 
about the position of the joystick — in fact, they can give us simultaneous 
information about ave joysticks — burt they do not yield this information easily, 
They also give us information about whether the joystick buttons are being 
pressed. This information is more easily decoded, so we'll talk abour it first. 


Reading the Joystick Buttons 

Two joysticks can be attached to the PC gameport at one time; we'll call these 
joystick A and joystick B. Each joystick has two buttons, which we'll call button 
| and button 2. This means that we can read the starus of up to four different 
buttons in the gameport byte. 

Bits 4 and 5 of the gameport byte represent the status of buttons 1 and 2 on 
joystick A. Bits 6 and 7 of the gameport byte represent the status of buttons 
| and 2 on joystick B. When one of these bits is set to 0, the equivalent button 
is being pressed, When one of these bits is set to 1, the equivalent button ts met 
being pressed, 

This is not exactly intuitive. One would expect it to work the other way 
around, with a | bit representing a button thats being pressed and a 0 bit 
representing a button that isv¢ being pressed. So we'll Hip the bits in the 
gameport byte before we send this information back to the calling program. We 
can do this with the assembly language NOT instruction, which changes 0s to 1s 
and Is to Os. A short assembly language routine for reading the gameport byte, 
Hipping the appropriate bits, and passing the resulting value back to a calling 
C/C++ program is shown in Listing 3-9. The calling program must provide a 
parameter for this function, telling it which joystick buttons the function should 
read. This parameter consists of a binary “mask” in which those bits are set to 1 


a Z 
a 7 
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that correspond to the bits in the gameport byte that the program is interested in 
reading. Well show you how to use this function in a moment. Nore thar the 
gameport is referred to in this function by the constant GAMEPORT, which is 
defined elsewhere in the TO.ASM module as equal to 0201h. 





i Listing 3-9 The reaqjbuttonl) function 


_readjbutton PROC 

; Read joystick Button specified by BMASK 
ARG bmask: WORD 
push bp 
mov bp,sp 


mov dx,GAMEPORT Point DX at joystick port 


ak 


mov ah,O ; Tero high byte of return value 

out dx,al ; Request data from port 

in -al,dx ; Get value from joystick 

not al ; Flip button bits 

mov bx,bmask ; Mask out all but requested buttons 
and al,bl 7; And Leave result in AX 

pop bp 

ret 


_readjbutton ENDP 


Determining the Stick Position 

Reading the position of the stick itself is a great deal more difficult. The position 
of joystick A on the x axis — that is, in the left and right direction — is 
represented by bit 0 of the gameport byte while the position of joystick A on the 
y axis — that is, in the up and down direction — ts represented by bit 1 of the 
gameport byte, Similarly, the position of joystick B on the x axis is represented by 
bir 2 of the gameport byte, while the position of joystick B on the y axis is 
represented by bir 3 of the gameport byte. 

How can a single bit in the gameport byte represent the position of a joystick? 
With great difficulry. When we first write random data to port 0201h and read 
the value of the gameport byte, the bits representing the various stick axes will 
always be set to 1, So we must continue reading the gameport byte from port 
0201h in a loop, until the bit corresponding to the stick axis that we are 
interested in is reset to 0. The amount of time that it takes for this to happen will 
tell us what position the stick is in on that axis. If it resets quickly, the stick 1s 
pulled to the left or up (depending on which axis we are measuring). If it resets 
slowly, the stick is pulled to the right or down. If ir resets in an intermediate 
amount of time, the stick is somewhere in the middle. Thus we must time the 
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number of loops required for the appropriate bit to reset in order to determine 
the stick position. 

The easiest way to do this is with the aid of two 80x86 assembly language 
instructions: TEST and LOOPNE. The TEST instruction tests the value of a 
specific bit in a specific register, while the LOOPNE instruction loops back to an 
earlier instruction as long as the result of the last operation (which in this case 
will be the TEST operation) wasnt 0. LOOPWNE also subtracts 1 from the value 
in the CX register every time it loops (and stops looping if that value reaches (0). 

If we test the bit of the gameport byte that we are interested in with TEST, we 
can use the LOOPNE instruction to keep looping until the bit resets to 0. And if 
we begin looping with a value of 0 in the CX register (which will roll over to 
FFFFh the first time LOOPNE execures, preventing the loop from terminating 
immediately), we can prevent the loop from taking forever to terminate — in 
case something is seriously wrong with the joystick hardware — while keeping a 
count of the number of times the loop has executed. Of course, since the value in 
CX is decremented rather than incremented every time the loop is executed, we'll 
need to subtract the value in CX from 0 to determine the actual number of times 
the loop repeated before the gameport byte was reset to 0. An assembly language 
function that does all of these things is in Listing 3-10, 





Listing 3-10 The readstick() Function 


_readstick PROC 
; Read current position of joystick on axis specified by BMASE 
ARG bmask: WORD 


push bp 

mov bp,sp 

elt ; Turn off interrupts, which could 
; effect timing 

mov ah,byte ptr bmask ; Get bitmask into ah. 

mov al,O 

mov dx,GAMEPORT ; Point DX at joystick port 

mov cx,0 ; Prepare to loop 65,534 times 

out dx,al : Set joystick bits to 1 

Loop2: 

in al,dx : Read joystick bits 

test al,ah , Is requested bit Cin bitmask) 
; Stilt Tf 

Loopne lLoopé ; If so Cand maximum count isn't 
; done), try again 

sti ; Count is finished, so reenable 
; interrupts 

mow ax,O0 


canfirraneel oat test peter 
| 


aes 


(Br 


ae a 
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comand pron: perrours paige 
sub ax,cx ; Subtract CX from zero, to get count 
pop bp 
ret 

_readstick ENDP 


Using the Joystick Functions 


The joystick functions are both simpler and more complicated to use than the 
earlier input functions in this chapter, No initialization is required before they 
can be used. And only two types of data are returned by these functions: stick 
position data and button data. 

Both the readjbutton() and readstick() functions are called with a sin gle 
parameter — a bitmask that tells the functions which bits to read in the 
gameport. So that you dont have to worry about which binary digits are which, 
we ve provided appropriate masks as constants in the [O.H file. These constant 
masks are JOY_X and JOY_Y, for reading the x and y axes of joystick A, and 
JBUTTON1 and JBUTTON2 for reading buttons 1 and 2 of joystick A. (You'll 
have to come up with your own masks for reading joystick B.) 

For instance, to read the x axis position of joystick A, call the readstick() 
function like this: 


int stickl=readstick(JOY_X); 
This will set the integer variable stee/ to the number of times the assembly 
language loop executed when timing the bit 0 of the gameport, which gives you a 
method of calculating the position of joystick A. (We'll show you how to use this 
value in a moment.) Similarly, to read the y axis position of joystick A, call the 
readstice() function like this: 
int stickl=readstick(JOY_YT); 

To read the status of button 1 on joystick A, call the readjburton() function 
like this: 
int buttonl=readjbutton(JBUTTONT): 
If the value returned by the function is non-zero, then button 1 is being pressed. If 
the value is 0, then it isnt being pressed. Similarly, to read the status of button 2 
on joystick A, call the readjéutton() function like this: 
int button2=readjbutton(JBUTTONZ) ; 
If you need to know whether one or the other of the buttons is being pressed, but 
dont care which one, you can read them both at the same time like this: 
int button=readjbutton( JBUTTONT+JBUTTON?) - 
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If the value returned by the function is non-zero, then one or both of the buttons 
is being pressed. If the value is 0, then neither is being pressed. Note that you 
cant use this trick with the reaastcé() function to read the value of che stick on 
both ax S simultaneously. Well, VOU caf, but the value returned would be 
meaningless. (Actually, it would be the greater of the x and y axis values, but 
there would be no way for you to tell which one it was.) 


Calibrating the Joystick 

The hardest part of using the joystick functions is hguring out what the value 
returned by the readsrick() function means, Recall thar this value is the number of 
times that the assembly language loop that read the stick value had to loop before 
the appropriate bit in the gameport reset to 0. But whar does this tell you about 
the physical position of the stick? 

Thats difficult to say, because on different computers it will mean different 
things. [he faster the computer, the more times the timing loop will execute 
before the bit resets to 0. So a number chat means the joystick is betng pushed to 
the right on a slow machine may mean the joystick is being pushed to the left on 
a fast machine. How do you determine what these numbers mean for the 
machine the program is actually running on? 

The answer is that you must calibrate the joystick before the game can begin. 
You must prompt the user to move the joystick to the extreme upper left and 
perform some action, such as pushing a joystick button, that will signal when the 
stick is in position. When this signal is received, you must call the readstick() 
function to find out what number is returned for that position. You must then 
repeat this operation for the center and lower right positions, noting the numbers 
tor each. Once you have these numbers, you can use them for determining the 
joystick positions while the game ts actually being played. 


The JOYSTICK Program 


Listing 3-11 demonstrates how to use the joystick functions in a program. The 
logic of the JOYSTICK.CPP program is similar to that of the MOUSE.CPP 
program ¢arlier in this chapter, though the need to calibrate the joystick makes 
this listing a bit more complicated. To keep things as simple as possible, weve 
calibrated only one set of reference values for the joystick — the ones for the 
center position. The program then loops repeatedly, measuring the joystick 
position on both axes and announcing if its to the left or right of, or exactly in, 
this central position. It also notes whether the buttons are pressed, When the 
second button is pressed, the program terminates. While running this program 
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(which is available on the disk as JOYSTICK.EXE), you'll note that it’s extremely 
difficult to get the joystick precisely in the center. In practice, we'll need to 
represent the center position as a range of values around this reference position, 
so that slight joystick slippage to either side won't be taken as a command from 
the user. [he output looks like this: 
X axis position: 

Left of center 
Y axis position: 

Above center 
Button 1 not pressed 
Button 2 not pressed 





Listing 3-11 The JOYSTICK.CPP program 


ff JOYSTICK.CPP 

if 

/f Demonstrates joystick interface functions 

ii 

// Written by Christopher Lampton 

// for Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 
Hinclude <stdlib.h> 
Finclude <conio.h> 
Finclude "“io.h" 


void main(void) 

{ 
int xstick,ystick; 
int xcent,ycent; 
int status|],status2; 


ff Clear the text display: 
clrser(}; 


ff Calibrate the user's joystick: 

printt("\ni\nCenter your joystick and press button "); 

printf("one.\n"); 

while (!readjbutton(JBUTTONT)?: // Loop until joystick 
// button pressed 

xcent=readstick(JOY_X); ‘/ Get x coordinate 

ycent=readstick(J0Y_Y); // Get y coordinate 

while (readjbutton(JBUTTON1T)); // Loop until button 
ff released 

f/f Set up display: 

clrseri): 
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gotoxy(20,10); 
printf("X axis position:”); 
gotoxy(20,12); 
printt("Y axis position:"),; 


// Read button ¢ status: 
statuse=readjbutton( JBUTTONZ); 


‘/ Loop until right mouse button 15 pressed: 
while('status2) { 


ff Read X and ¥ axis positions: 
xStick=readstick(JOY_XM); 
ystick=readstick(JOY_Y); 


‘f Write joystick positions on display: 
gotoxy(20,11); 

if (xstick<xcent) printt(" Left of center "); 
if (xstick>xcent) printt(" Right of center"); 
if (xstick==xcent) printf(" Centered sat 
gotoxy(20,13); 

if (ystick<ycent) printft(" Above center"); 

if (ystick>ycent) printf(" Below center"); 

if (ystick==ycent) printf(" Centered Li i 


‘/ Read mouse button status: 
statustl=readjbutton(JBUTTON1) ; 
statuse=readjbutton( JBUTTONZ); 


// Write button status on display 
gotoxy(20,14); 

if (status?) printft("Button 17 pressed mike 
else printT("Button 1 not pressed"); 
gotoxy(20,15); 

if (status2) printf("Button 2 pressed de Be 
else printf("Button 2 not pressed"); 


The Event Manager 


The low-level input functions that we have been developing in this chapter can 
be called directly from a game program to determine what sort of input 
commands are coming from the user through the input device of choice, be it the 
key ‘hoard, joystick, OF Mouse. It would make Our liv rom ld Propraim Mets a lot 
easier, though, if there were some sort of protective layer between the game 
program and the raw data | input by these low-level functions, a protective layer 
that would translate this raw inpuc into a form more appropriate for our game. 


# 
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That's the job of an event manager. An event manager is a routine or set of 
routines that monitors the input from the low-level functions and passes on only 
the information needed by the rest of the program, in a form that the program 
can easily use. Unlike our low-level input functions, which can be used in pretty 
much the SeLITLe form by just about any ctype of COW PUter Prop Pa from all 
spreadsheet to a flight simulator, the event manager will be custom-designed for 
the type of program with which we intend to use it. 

In this chapter we want to write an animated maze exploration program based 
on the maze-drawing routines presented in the last chapter. It would be 
appropriate for such a program to receive input from the user concerning the 
type of movement that the user wishes to make through the maze. For instance, if 
the user wishes to move forward down a corridor of the maze, he or she could 
press the key, push the joystick forward, OF Move the Misc forward On the 
desktop. If the user wishes to rotate to the right, he or she could press the G) key, 
push the joystick to the right, or move the mouse to the right. And so forth. 

The event manager for such a program could watch for the appropriate actions 
to be performed, then translate those actions into a set of “movement events” 
which could be passed back to the game program. If the user pushes the joystick 
forward, for instance, cl “forward movement. event could be returned Ct) the 
program. Similarly, if the user presses the right arrow key, a “rotate right’ event 
could be returned to the program. The program need not know whether these 
events were generated by the joystick, the mouse, or the keyboard (or by some 
even more exotic input device that weve added to the event manager at the last 
moment, such as a touch screen or data glove). The program only needs to know 
that the user has requested forward movement, so that it can try to provide what 
the user wants. The program can then be written without any specife concern 
for the nature of the input devices thar are generating these events. 


Maze Events 


Before we can write the event manager, then, we need to decide on the set of 
events that will be required by a simple maze exploration program. The event 
manager we develop in this chapter will recognize five types of event, which welll 
call go_forward, go_back, go_left, go_right, and quit_game. To pass these events 
from the event manager to the calling program, we'll use an evens strecture that 
we ll define like this: 

// Structure for passing events to calling program: 


struct event struct 7 
int go_forward,go_back,go_Left,go_right,quit_game; 
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We'll place this definition in the hle EVNTMGRI.H. The “1” in the file name 
indicates thar this will not be the last event manager that we create in this book. 

The event structure will be declared by the calling program and passed to the 
event manager as a parameter. [The event manager will then change the value of 
the fields in che structure to indicate what events have occurred and pass it back 
to the calling program. When the event manager sets a held in the structure to a 
non-zero value, it indicates that the event has occurred (or ts still occurring, in 
the case of continuous events such as keys being pressed or sticks being pushed). 
Because more than one held can be set to a non-zero value at the same time, the 
event manager can pass multiple events back to the calling program. For 
example, this structure could be used to indicate that the user wants to move 
forward and turn right simultaneously. 


The init_events() Function 

The event manager will be intrialized by calling the rit_events() function, shown 
in Listing 3-12. This does nothing more than initialize the low-level keyboard 
and mouse handlers. (The joystick handler doesn't require any initialization, 
although the user's joystick will need to be calibrated.) The address of a 128-byte 
array of rype char called keybuffer (defined elsewhere in the event Manaeer 


module) is passed to the keyboard handler. 






Listing 3-12 The init_events() function 


void init_events() 

ff Initialize event manager 

{ 
initkey(keybutfer) ; ‘/ Install alternate keyboard driver 
initmouse(); ff Initialize the mouse driver 

} 


The Joystick Calibration Functions 


There are three functions for calibrating the joystick: one that determines 
the center positions in both axes (the setcenter() function), one that determines the 
farthest up and left positions (the setmfa() function), and one that determines 
the farthest down and right positions (the setmax() function), The values for 
these positions are stored in a set of variables that are global to the event manager 
module, so they can be used later to determine whether the joystick is pointing to 
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the left or right, up or down. These functions must be called during the 
initialization of the game, after the user has been instructed to move the joystick 
into the appropriate positions and press joystick button 1. The text of the 


functions appears in Listings 3-13, 3-14, and 3-15, 





“=%a5 Listing 3-13 The setcenter() function 


void setcenter() 


// Set center joystick coordinates 


f 


while ¢!readjbutton(JBUTTON1)); 


xcent=readstick(JOY_X); 
ycent=readstick(JOY_Y); 
while (readjbutton(JBUTTON1)); 





void setmin() 


ff Loop until joystick 
‘/ button pressed 

// Get x coordinate 

‘f Get ¥ coordinate 

ff Loop until button 
// released 


Listing 3-14 The setmin0) function 


ff Set minimum joystick coordinates 


{ 


while €!readjbutton(JBUTTON1T)); 


xmin=readstick( JOY x); 
ymin=readstick(JOY_Y); 
while Creadjbutton(JBUTTON1)); 





‘f/f Loop until joystick 
// button pressed 

if Get x coordinate 

‘/ Get y coordinate 

‘/ Loop until button 
‘f released 


== Listing 3-15 The setmax() function 


yoid setmax()} 


if Set maximum joystick coordinates 


{ 


while €!readjbutton(JBUTTONT)); // Loop until joystick 


xmax=readstick(JOV_x); 
ymax=readstick(JOY_Y); 


‘f button pressed 
‘* Get x coordinate 
‘/ Get y coordinate 
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while Creadjbutton(JBUTTONT)); #/ Loop until button 
/‘/ released 


The getevent() Function 

The main body of the event manager is the getevens() function. This function 
takes two parameters: an integer bitmask specifying which types of events are 
desired, and an event structure in which the current events (as it were) will be 
returned. The bitmask consists of the constant values KEYBOARD EVENTS, 
MOUSE _EVENTS, and JOYSTICK EVENTS (defined in EVNTMGRI.H) 
added together as desired. For instance, to obtain keyboard events and joystick 
events, you would call the event manager like this: 


getevent (KEYBOARD _EVENTS+JOYVSTICK_EVENTS, Eevents); 


where events is a pointer to a variable of type event_structure. 
The getevent() function begins its work by clearing any previous events out of 
the event structure variable chat it is to return events In: 


// Clear any events in structure: 


events—>qgo_forward=0; 
events=>go_back=0; 
events->go_Left=0; 
events—>go_right=0; 
events=>quit_game=0; 


If joystick events have been requested, it then calls the low-level joystick 
functions to determine if any events have occurred. If they have, it sets che 
appropriate helds in the event structure: 


‘/ If joystick events requested.... 

if (event_mask & JOYSTICK_EVENTS) { 
if (readstick(JOY_T)<(xcent-4)) events->go_forward=1; 
if (readstick(JOY_Y)>(xcent+10)) events->go_back=1; 
if Creadstick(JOY_X)<(xcent=<4)) events=<->go_Left=1; 
if Creadstick(JOY_X)>(xcent+10)) events->go_right=1; 
if (readjbutton(JBUTTONT)) events—>quit_game=1; 


If mouse events have been requested, then the event manager calls the low- 
level mouse functions to determine if any events have occurred. If they have, it 
sets the appropriate helds in the event structure: 

‘f If mouse events requested.... 


if Cevent_mask & MOUSE_EVENTS) ¢ 
relpos(&x,By); // Read relative mouse position 
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if (readstick(JOY_Y)<(€xcent-4)) events->go_forward=1; 
Vf Creadstick(JOY_T)>(xcent+10)) events->go_back=1; 
if (readstick(JOY_X)<(xcent-4)) events->go Left=1; 

if Creadstick(JOVY_Z)>(xcent+10)) events->go_right=1; 
if Creadjbutton(JBUTTONT)) events<—>quit_game=1; 


If mouse events have been requested, then the event manager calls the low- 
level mouse functions to determine if any events have occurred. If they have, it 
sets the appropriate helds in the event structure: 


// If mouse events requested.... 
if (event_mask & MOUSE EVENTS) £{ 
relpos(&x,@y); // Read relative mouse position 
if (y<-5) events=—>go_forward=1; 
if (y>5) events->go_back=1; 
if (x<-20) events->go_ left=1; 
if (x=20) events->qo_right=1; 
int b=readmbutton(); // Read mouse button 
if (bEaMBUTTONT) events->quit_game=1; 


Finally, if keyboard events have been requested, the event manager checks the 
keybuffer array to determine if any events have occurred. [f they have, it sets the 
appropriate helds In the eCvVent structure: 


‘/ If keyboard events requested.... 
if Cevent_mask & KEYBOARD_EVENTS) 7 
if CkeybufferlFORWARDEEY]) events—>qo_forward=1; 
if (keybufferCBACKKEY]) events=—>go_back=1; 
if (keybufferCLEFTKEY]) events->go_left=1; 
if (keybufferCRIGHTKEY]) events—>go_right=1; 
if CkeybufferlQUITKEYJ) events->quit_game=1; 
I 


The constants used here for the keyboard scan codes are defined tn the 
EVNTMGRI.H file. FORWARDKEY is the scan code for the (®) key, 
BACKKEY is the scan code for the @ key, LEFTREY ts the sean code for the 
key, RIGHTKEY is the scan code for the (3) key, and QUITKEY is the scan code 
for the key. However, the definitions of these constants can be changed in 
the header file so that any set of five keys can be used to trigger these events. For 
instance, the scan code for the *¢* key on the keypad could be assigned co 
FORWARDKEEY, and so forth. By using variables in place of these constants, a 
game program could be designed in such a way that the player could redefine at 
any time the keys used to trigger the events, perhaps from a special configuration 
screen. 
The complete text of the getevent() function appears in Listing 3-16. 
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events-=go_right=0; 
events—>quit_game=0; 


ff If joystick events requested.... 

if Cevent_mask & JOYSTICK_EVENTS) ¢ 
if (readstick(JOY_Y)<(xcent-4)) events->go_forward=1; 
if (readstick(JOY_Yi>(xcent4+10)) events<>go_back=1; 
if Creadstick(JOY_xX)<(xcent-4)) events->go_left=1; 
if (readstick(JOY_X)>(xcent+10)) events->go_right=1; 
if (readjbutton(JBUTTON1)) events->quit_game=1; 


‘/ If mouse events requested.... 

if Cevent_mask & MOUSE_EVENTS) @ 
relpost&x,8y); // Read relative mouse position 
if (y#=<5) events<->go_forward=1; 
if (y>5) events->go_back=1; 
if (x<-20) events-—>go_Left=1; 
if €x>20) events<>go_right=1; 
int b=readmbutton(); // Read mouse button 
if (bEMBUTTONT) events—>quit_game=1; 

} 

‘! If keyboard events requested... . 

if Cevent_mask & KEYBOARD_EVENTS) f 
if CkeybufferlLEORWARDKEYI) events=<>go_Torward=1; 
if (keybuffer(CBACKKEY]) events->go_back=1; 
if (keybufferCLEFTKEY]) events—>go_Left=1; 
if (keybufferCRIGHTKET]) events=>go_right=1; 
if (keybufferlQuITKEY]) events->quit_game=1; 


Animating the Maze 


We now have almost all the tools we need for an animated tour of the maze we 
created a still picture of in the last chapter. You might think that the animation 
itself would require a great deal of additional code, but thats not true. Animation 
is simply a matter of drawing a sequence of successive images on the computer 
display, erasing one image, and then drawing the next image on top of it. In the 
last chapter we developed the code thar draws the image; in his chapter we 
developed the code that allows the user to interact with that image. Now all we 
have to do is put them together and we have a game. Well, almost... 

We'll reuse much of the same code we used tn our maze-drawing program in 
the last chapter. We ll add some instructions to that code, to initialize the event 
manager and calibrate the joystick: 


// Initialize event manager: 
init_events(); 
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‘ff Calibrate the user's joystick: 

if CWHICH_EVENTS & JOYSTICK_EVENTS) ¢@ 
printt('\nCenter your joystick and press button "?; 
printt("one.\n"); 
setcenter(); // Calibrate the center position 
printf("Move your joystick to the upper Lefthand “); 
printt¢("corner and press button one. \n"); 
setmin(); ‘/ Calibrate the minimum position 
printt("Move your joystick to the Lower righthand "); 
printt("corner and press button one.\n"); 
setmax(); ‘f Calibrate the maximum position 

} 


We'll need a method for timing the frames of the animation, so that they dont 
Hash by too quickly on faster machines (or too slowly on slower machines). We ll 
do this by calling the C/C++ library function ecfock(), defined in the header file 
TIME.H. This function returns the number of treks that have transpired since 
the program has started running. How long is a ck? That may vary from 
computer to computer, so the C/C++ compiler maintains a special macro called 
CLK TCK that can be used to obtain the number of clock ticks in a second. To 
determine how many ticks we wish to wait berween animation frames, we'll 
establish a constant called FRAMES PER SECOND, which we'll initially define 
as being equal to 6: 


Hdefine FRAMES PER_SECOND 6 


Then we'll divide CLK_TCK by frames per second to obtain the number of ticks 
per frame: 


// Set number of ticks per frame: 
ticks per_frame = CLK_TCK / FRAMES _PER_SECOND; 


So that well know just how much time the first frame of the animation takes, 
we Il record the current tick count in the variable fast_frame. This variable must 
be of type cleck_#, a special data type defined in the TIME.H header fle (which is 
usually just a long integer): 


‘f Initialize the frame timer: 
clock_t Lastframe=clock(); 


Since our animation loop will continue until a quit_game event occurs, we 
need to be sure that the quit_game held in the events structure — the structure of 
event_type that we ll be using to pass events trom the event manager — Is set to 0, 
so that the animation loop will execute at least once: 
ff Make sure we get at Least one frame 


// into the maze: 
events. quit_game=0; 
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Then we start executing an animation loop thar will continue executing as 
long as no quit_ game events occur: 


‘/ Let's go for a walk in the maze: 
while(!events.quit_game) f 


We then call the d@rzwmaze() function that we developed in the last chapter to 
draw our initial position in the maze (which is defined by the same set of 
variables established in the last chapter): 


‘* Draw the maze in screen butfer: 
drawmaze(screen_butfer); 


So that the image of the maze is not whisked too quickly from the display, we 
must pause until a number of clock ticks has passed equal to the treks_per_frame 
value that we established a few instructions ago: 


‘/ Pause until time for next frame: 
while ({clock()-LastTrame)<ticks_per_trame?; 


We must then reset the value of the lastframe variable to the current tick count: 


‘f Start timing another frame: 
lastframe=clock(); 


If any’ Mmavement events have occurred, we || need to change OUT position 
within the maze. So we call the event manager to check for input: 


ff Check for input events: 
getevent (WHICH _EVENTS,&events); 


Should a go_forward event occur, well want to move to the next position in 
the maze along our current heading, Youll recall from the last chapter that our 
position within the maze is contained in the variable pos, which is of rype xy (that 
is, It consists of an x held and a y feld) and our heading is contained in the 
integer variable direction. The forward increments along that heading are 
contained in the array element imcrement/direction/, which is also of type xy. 
By adding the value of trerement/direction].x to our x position and 
increment/direction|.y to our y position, we can determine our next position along 
the current heading. However, we'll first assign this position to a temporary 
variable of type xy called mewpos, so that we can test to see if the maze square at 
this position is empty before we change our actual position. If the next square is 
not empty, we cant move into it, because theres a wall in the way: 

‘/ Do we want to move forward? 

if (events.go_forward) { 

newpos.x=pos.x+incrementCdirectionl.«; 
newpos.y¥=pos.y+increment(directionl].y; 
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if (!mazeCnewpos.x]Cnewpos.yJ) f 
pos.x=newpos.«; 
pos. y=newpos.y; 
} 
} 


If a go_back event has occurred, we'll want to do the same thing in the 
direction opposite to our current heading. However, we'll make these instructions 
part of an else, so we cant move both forward and backward should the player be 
pressing both keys simultaneously: 


ff ...0P do we want to move backward? 
else if (events.go_back) { 
newpos.x=pos.*x-increment(Cdirection].x; 
newpos.y=pos.y-incrementCdirection).y; 
if ('mazeLnewpos.xiCnewpos.yJ) f 
pos. x=newpos.x; 
pos. y=newpos.y; 


Well also want to check to see if a go_right or go_left event has occurred. If 
so, we ll rotate our heading clockwise or counterclockwise, respectively: 


// Do we want to turn Left? 
if fevents.go_Left) f 
—direction; 
if (direction<0) direction=3; 
} 


‘/ ...0f do we want to turn right? 
else if (events.go_right) f 
direction++; 
if (direction=3) direction=0; 
} 
} 

And that’s the end of the animation loop. Everything is now set up for the 
ext frame of the animation, which will be drawn by the call to the drawenaze() 
function that we placed at the top of the loop. 

When the loop terminates, well need to deinstall the event manager: 


ff Terminate event manager: 
end_events(); 


Fixing the Flicker 


What sort of animation will this loop produce? Alas, not quite the type we want. 
The program GOMAZEL.EXE on the disk is written exactly as we have described 
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here. Run it and you'll see immediately whats missing. You can move through the 
maze by pressing the keys on the keyboard, but the animation of the maze 1s 
marred by an irritating Hicker. What causes this flicker? Youre watching the image 
of the maze being drawn — and erased — six times a second. It makes sense that 
such an image would Hicker, because irs constantly vanishing and reappearing. 

How can we fx this flicker? By drawing and erasing the maze in an offscreen 
buffer — and only moving the image onto the screen once its complete. That 
way, one complete image will rapidly replace another complete image on the 
video display, with no Hicker in sight. To accomplish the task of moving the 
image from the buffer to the display, well need a fast assembly language function 
to move a rectangular segment of memory into video RAM. Why not move the 
whole contents of the buffer into video RAM? Because it takes too long. We only 
need to move thar section of the screen that actually contains the maze. We'll use 
the putwindow)) function, developed in the last chapter, for that task. 


The GOMAZE Program 


The final version of the main() function of the GOMAZE.CPP program appears 
in Listing 3-17. 





a 


Listing 3-17 The main0 function of the GOMAZE.CPP 
program 


void mainfvoid) 
{ 


int scan; 
event_struct events; 
STruct xy¥Y Newpos; 


‘f Initialize event manager: 
init_events(); 


ff Calibrate the user's joystick: 

if C(WHICH_EVENTS & JOYSTICK_EVENTS) ¢ 
printt(’\nCenter your joystick and press button "); 
printf( "one. \n"); 
setcenter(); // Calibrate the center position 
printt( "Move your joystick to the upper lLefthand "); 
printt("corner and press button one.\n"); 
setmin(); if Calibrate the minimum position 
printt("Move your joystick to the Lower righthand "); 
printft("corner and press button one.\n"); 


COME oN NeXT page 
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cone from previews page 
setmax(); /* Calibrate the maximum position 
} 


f/f Create pointer to video memory: 
char far “screen=(char far *)JMK_FP(Oxal00,0) ; 


ff Create offscreen video buffer: 
char far *screen_buffer=new unsigned char [Cé4000); 


// Save previous video mode: 
int oldmode=*Cint *)MK_FP(0x40,0%49) ; 


// Put display in mode 13h: 
setmode(Qx13); 


ff Clear display: 
els(screen_buffer); 


// Draw window on display: 
drawbox(screen_buffer); 


// Set number of ticks per frame: 
ticks_per_frame = CLK_TCK / FRAMES PER_SECOND; 


ff Initialize the frame timer: 
clock_t lastframe=clock(); 


‘/ Make sure we get at Least one frame 
/f into the maze: 


events.quit_game=0; 


‘f/f Let's go for a walk in the maze: 
whilet!events.quit_game) f 


// Draw the maze in screen buffer: 
drawmaze(screen_buffer); 


'*f Move screen buffer to screen: 
putwindow(0,0,320,200,screen_buf fer); 


/f Pause until time for next frame: 
while ((clock()-Lastframe)<ticks_per_frame}); 


// Start timing another frame: 
Lastframe=clock(); 


ff Check for input events: 
getevent(WHICH_EVENTS,&events) ; 


// Bove viewer according to input events: 


‘/ Do we want to move forward? 
if Cevents.go_forward) f 
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newpos.x=pos.x+incrementldirectionl.x; 
newpos.y=pos.y+incrementCdirectionl.y; 
if ¢'mazeCnewpos.xJCnewpos.yl) f 
pos. x=newpos.x; 
POS. ¥=NeWpos.¥; 
I 
} 


/f ...0r do we want to move backward? 
else if Cevents.go_back) f 
newpos.x=pos.x-incrementCdirectionl.«x; 
newpos.y=pos.y-increment(Cdirectiond.y; 
1f C'mazeLnewpos.xJEnewpos.yl) ¢ 
pos. X=Newpos. x; 
pos. Y=newpos.y; 


} 


// Do we want to turn left? 
if Cevents.go_Left) f 
—-direction; 
if (direction<0) direction=3; 
} 


/f ...0r do we want to turn right? 
else if Cevents.go_right) f 
direction+; 
if (direction>3) direction=0; 
} 
} 


// Terminate event manager: 
end_events(); 


// Release memory 
delete screen_buffer 


ff Restore old video mode: 
setmode(oldmode) : 
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se» ets be honest. [he wireframe maze animation that we created in 
the last two chapters, while ir illustrated principles of graphics 
output and device inpur that cewlad be used in a state-of-the-art 

game program, was not exactly of commercial quality itself. To 





| | the best of mv knowledge, the last major commercial Baume that 
featured wireframe maze graphics was Wizardry V, published in 1989. And that 
game looked like something from the distant past even at the time of its 
publication. More recent installments in the Wizardry series have made quantum 
leaps beyond the simple wireframe mazes of the frst five entries. As entertaining 
as the early Wizardry games were (and still are), no serious game programmer can 
get away with this sort of simplistic maze animation in the 1990s. 

So, in this chapter, were going to make a quantum leap of our own, Well 
throw the wireframe maze graphics aside and build the core of a birmapped maze 
engine similar to those used in such up-to-rhe-minute games as Eye of the 
Beholder 1, 2, 8¢ 3 and Wizardry VIL: Crusaders of the Dark Savant. This engine 
will use many of the programming principles that weve discussed in the last nwo 
chapters, but what you'll see on the screen will no longer be white lines on a 
black screen. Instead, you'll see a realistic, full-color animated maze that could 
have leaped right out of one of the games on the current software bestseller list. 
As a bonus, well show you how to generate new graphics for this maze engine 
using software that can be obtained quite inexpensively or even (if you play your 


cards right} for free. 


I 
‘407 
| : 
‘tor 


GARDENS OF IMAGINATION 


These bitmapped maze graphics will be constructed out of predesigned 
graphic bitmaps, which (as it happens) we'll be creating using the ray-tracing 
program POV RAY. You Leaf) Lec other methods for constructing birmapped Mae 
eraphics — so-called “paint” programs like Electronic Arts Deluxe Paint are an 
excellent way to create bitmaps, if you have the requisite artistic talent (or can 
afford to hire the services of someone who does), Nevertheless, a ray tracer is a 
great way to throw together quick-and-dirty graphics of surprising beauty and 
realism, especially if you are less than deft at painting pixels yourself. 

Before we can use the bitmaps created by POVRAY to create a maze, though, 
we must have some method of storing these bitmaps on disk and loading them 
into the computer. So in the frst portion of this chapter, well concentrate not on 
creating bitmaps, but on storing and retrieving them from disk. 


What Is a Bitmap? 


We saw in chapter 2 how computers like the IBM PC and its clones store the 
current video Image in memory as a sequence of byte values representing either 
characters or pixels on che display. In mode 13h, each byre in video memory 
represents the color of a corresponding pixel on the screen, Because these bytes of 
data, like all numbers held in the electronic circuitry of a computer, are made up 
of individual binary digits, or bits, its common to refer to this method of 
representing pixels as a bitmap. In the case of mode 13h, it might seem more 
appropriate to use the term “bytemap, but the term bitmap goes back to the 
days when it was ear to describe the state of pixels on the typical video 
display using only | or 2? bits within a byte. This ts still the case with the PC's 
CVO- and four-color graphics modes, but as COM puter graphics Mavic into the era 
af 256-color images and bevond, bitmaps made of individual bits are becoming 
increasingly less common. Now 4 or 8 or even 24 bits per pixel may be required. 
Bitmaps aren't always stored in video memory, In the last chapter, we stored 
the bitmap representing the next frame of animation in an offscreen bufter in 
video RAM until we were ready to move it onto the video display. For longer- 
rerm storage, its quite possible to store bitmapped images in a disk file on a hard 
drive or CD ROM. In fact, most computer games store their graphics in precisely 
this way. If you've ever wondered why the typical computer game takes up several 
megabytes of space on your disk, its probably because the game includes a vast 
library of 256-color bitmapped images stored in the same directory with the 
game, or in one of the subdirectories off of that directory. (Digitized sound hles 
are also a popular method of burning up large amounts of disk storage, especially 
in the case of CD ROM-based games, which cypically have about half a gigabyte 
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of storage available to devote to this and other types of data.) When the game 
needs to display these graphics, the contents of the files are read from the disk 
and copied into video memory, often by way of one or more off-screen butters, 

What form do 256-color graphics take when stored on a disk? In some cases 
they are stored in exactly the same way that they are normally represented in 
video memory, as a sequence of byte values representing the pixels on the display, 
perhaps with a list of 256 color descriptors (each consisting of 3 bytes of color 
data, as described in chapter 2) appended to the end of the file so that the image's 
palette can be reconstructed when its displayed. This is nor, however, a 
particularly efficient way of storing an image, Quite often, the graphics are stored 
in compressed format, with as much redundant information as possible squeezed 
out of them. If you think the games on your hard drive are taking up a lor of 
space mow, you should see how much space theyd take up if their graphics werent 
compressed! 

In this chapter we ll be constructing images of a maze out of predrawn 
bitmaps. We'll need vo store those bitmaps on the disk before we can use them. 
[t's important that we give some thought about how were going to do this, so 
lets consider some possible formats in which we could store the files. 


Graphics File Formats 


There are probably an infinite number of different ways in which graphics 
bitmaps can be stored in a disk hle. Fortunately, we dont have to reinvent the 
wheel, There are a number of standard file formats available for us to use. Let's 
look at a few of them and See what SOre of strengths and weaknesses they have. 

The CX format was developed in the mid-1980s for a program called PC 
Patntbrush, published by “Soft, (The formar is also referred to as PC Paintbrush 
format or ZSoft format.) This is probably the single most widely supported 
graphics hle format for the PC. Although the data compression algorithm used to 
squeeze the redundancy out of the files isnt the most efficient, its very easy (and 
fast) to decompress. PCX files are identified by a file extension of .PCX, as in 
IMAGE.PCX, 

The Graphics Interchange Pile (GIF) tormat was developed by the CompuServe 
Information Service as a means of viewing graphics while logged on to the service 
via modem. Although files in this format were originally intended primarily for 
on-line viewing, the GIF (pronounced “jiff") format has also become quite 
popular as a means of distributing graphics images from computer to computer. 
The compression scheme is more eHective than the one used in PCX files, but it’s 
also harder (and somewhat slower) to decode. GIF files are identified by an 
extension of GIF, as in IMAGE.GIF 
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The darga fle format (GA) is named after a line of graphics add-on boards 
sold by the Targa company. Because the most popular Targa boards are those that 
offer 24-bit color (that ts, bitmaps that represent each pixel with 3 bytes of data 
and therefore can contain up to 16 million different colors at one time), most 
Targa hles contain 24-bit images. These images are stored in so-called direct color 
format, in which each pixel is represented by a 3-byte color descriptor, with 8-bit 
values for the red, blue, and green intensities of the color. These files contain no 
palette, since any palette information would be redundant, the color information 
being stored in the bitmap itself. However, the Targa format also allows for the 
storage of 8-bit (256-color) images with an attached palette. Targa files are often 
uncompressed. This format is quite popular, in part because of the simplicity of 
the uncompressed Targa format and in part because its the most widely known 
method of storing 24-bit images (though uncompressed 24-bit image files can be 
quite large). Targa files are identified by an extension of . TGA, as in 
IMAGE. TGA. 

A large number of other formats are available, such as the Windows BA{P 
(short for bitmap) format. If youd like a detailed survey of the most common 
ones, you might want to take a look at the book Graphics File Formats 
(Windcrest/McGraw Hill, 1992) by David C. Kay and John R. Levine. No 
graphics programmer should be without at least one reference to the standard PC 
file formats, and this is a particularly useful one. 

In this chapter we'll use files in two different formats, the uncompressed 8-bit 
TGA format and the PCX format. I've chosen the latrer because t's supported by 
a wide variety of graphics utilities and it provides an easily decoded compression 
scheme. I've chosen the former because it is simple to implement and happens to 
work well with the graphics utilities that | used to create the maze bitmaps that 
we Il use in the maze program that we develop in this chapter. Let's look at these 
two formats in turn, 


The 8-Bit Targa Format 

The 256-color, 8-bit Targa fle format is actually rather rare, having been eclipsed 
long ago by the 24-bit version. However, in creating the graphics for the maze 
program in this book, | used the public domain Persistence of Vision ray tracer 
(better known simply as POV or POWRAY) and the public domain Piclab 
graphics conversion utiliry, both of which work well with Targa files. POVRAY 
stores the images it creates in the 24-bit Targa format. Piclab is easily used to 
downscale these 16 million color images to 256-color images, and will store the 
converted images as 8-bit Targa files, which can be viewed on PCs without 24-bit 
graphic adapters. (It will also store the converted images as GIF files, but the GIF 
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compression scheme is more complex to decode.) 1 decided thar it would make 
my job a great deal easier if | included routines in the bitmapped maze program 
to support the 8-bit Targa formar. 

Like almost all types of graphics files, Targa files begin with a header 
containing information about the image or images that the file contains. (Some 
eraphics file formats allow more than one image to be stored in a file, though 
none of the files on the disk that accompanies this book are stored that way.) 
We'll need some of the information in this header, so the first thing well want to 
do is read it off the disk. The easiest and most elegant way to do this is to declare 
a data structure with precisely the same fields as the header and read the header 
from the fle using the C/C++ read() function. The definition for the Targa 
header appears in Listing 4-1. 





Listing 4-1 The toa_header structure 


struct tga_header f{ 


BYTE ID_Length; ff Length of ID field 
BYTE color_map_type; ff O=direct color, else palette 
BYTE image_type; // Type of Targa image 
WORD first_color_map_entry; // First palette color 
WORD color_map_Length; ff How Long 16 palette? 
BYTE color_map_entry_size; // How long is color descriptor? 
WORD image_x_origin; // Upper Left corner xX 
WORD image_y origin; ff Upper Left corner ¥ 
WORD image_width; ff Width in pixels 
WORD image_height; /f Height in pixels 
BYTE bits _per_pixel; /f How many bits describe pixel? 
BYTE image_descriptor_bits; // Description of image 
}; 


The data types BYTE and WORD are aliases for wnstgned char and unsigned 
int, which I've defined along with this header in the fle TARGA.H in an attempt 
to make the code less cluttered. 

This header is followed in turn by an image ID, which is an optional string of 
characters identifying the image — a name, if you will. The length of this string 
is defined by the /D_Jength field in the header. Not all Targa files contain an 
image ID, so this byte will often be equal to 0. Nonetheless, well have to check 
for this when loading a Targa file, so that we can handle the image ID if it’s there. 

The image ID is followed by the color map, which is roughly equivalent to the 
paletre thar we discussed in chapter 2. As with the image ID, not all Targa files 
contain a color map. In fact, since the popular Targa 24-bit formar uses a direct 
color bitmap rather than a palette-mapped structure, rhe color map ts rather rare in 
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Targa files. Nonetheless, we'll be using color-mapped Targa files in a couple of the 
programs that we create in this chapter, so welll need to deal with the color map. 
Although the color map can take several forms, we'll deal with 24-bit color maps, 
identifed by a value of 24 in the color_map_entry_size held of the header. These 
color maps are similar but not identical to WGA 256-color palettes, so we'll need to 
do some converting when we load the color map. More about that in a moment. 

Following the color map is the bitmapped image itself. Like the color maps, 
this bitmap can take several different forms. In this chapter we'll deal exclusively 
with 8-bit images, identified by a value of 8 in the #its_per_ pixel held of the 
header. The bitmap for an 8-bit uncompressed Targa image is identical to the 
bitmap used in VGA mode 13h: a sequence of bytes representing pixels in which 
each byte corresponds to one of the 256 color descriptors in the color map. We 
can read the image data directly into an array, where we can store it prior to 
putting the bitmap (or portions of the bitmap) on the display, 

That's pretty much all there is to an 8-bit uncompressed Targa file. Now let's 
look at some code for loading Targa files into memory. 


An 8-Bit Targa Loader 


The 8-bit uncompressed Targa format is so simple that we really only need a 
single function to load the files into memory. We'll call that function load TGA). 
The letters TGA refer to the file extension used on all types of Targa files. The 
prototype for this function, which we'll place in the header file TARGA.H, ts 


int LoadTGA(char far *filename,tga_struct *tga) 


The parameter filename is a string of characters containing the pathname of the 
‘Targa hle to be loaded, relative to the current directory. The parameter tea is a 
pointer to a variable of type tea_struect, which is defined in the TARGA.H header 
file as 
struct tga struct { 
tga_header header; 
char far *ID; 
BYTE far *image; 
BYTE far *color_map; 
Ie 
This structure has felds tn it equivalent to all parts of a Targa file. The header is 
actually stored within the structure in a field of type tea_beader, which we 
defined back in Listing 4-1. The other fields are pointers to the ID string, the 
image bitmap, and the color map, respectively. We'll need to allocate space for 
these structures from the heap before loading them off the disk, 

Before we can do this, however, we need to load the header from the disk, 
because it contains important information abour the fle. If we were writing a 
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full-service Targa loader that could handle all types of Targa files, wed use the 
header information to determine whether to load a direct color or palette- 
mapped image, whether to load a color map from the file, what format the color 
map and bitmap were to take, and so forth. However, since well only be loading 
&-bit palette-mapped uncompressed Targa fhles, well be using the header 
primarily to decide whether the fle that we have been asked to load is indeed 
such a file. If it isnt, well abort the foad/ GA) function and return an error 
message to the calling function. 

To open the Targa file that weve been requested to load, we frst call the 


C/C++ apen() function: 


if (Cinfile=open(filename,O_BINARY)) == -1) return(-1); 


The epen() function, called with these parameters, will search for a fle with the 
path name that was passed to the lead TGA) function in the filename parameter. 
If found, it will treat this file as a binary fle — thar is, as a fle made up of 
unsigned byte values that dont represent ASCII characters, If the file isn't found, 
the open{) function returns a value of -1. In that event the /oad/GA/) function 
will do the same, aborting the function and returning a value of -1 to the calling 
function, indicating that an error has occurred. (We'll use the -1 value to 
represent all rypes of errors encountered by this function.) 

Now thar the file is open, we'll use the deek() function to place the DOS file 
pointer at the beginning of the file (which is where we want to begin reading) 
and the rea@f) function to read the header from the file into the Jeader held of 
the fa structure: 

LseekCinfile,OL,SEEK SET); 
read(infile,&(tga->header),sizeof(tga_header)); 


We pass both functions the file handle returned by the epen() function, which is 
contained in the variable infile. The read{) function also requires a pointer to the 
header field of the tga variable and the number of bytes to read into the structure, 
which weve determined by calling the stzeof{) function. This standard library 
function returns the size of a variable structure, which in this instance 
corresponds to the number of bytes of data that we wish to read into it. 

Once we've read the header data into the Aeader held of the tga variable, we 
can access fields within the header the way wed access any other variables within 
a structure, Well use this capability to make sure that the image in the Targa fle 
is of the type that we're expecting. If it isn't, we abort with an error code: 
if (tga->header.image_type '= 1) return(-1); 
if (tga->header.image_width> 320) return(=1); 
if (tga->header.image_height > 200) return(-1}; 
if (tga->header.bits_per_pixel '= 8) return(-1); 
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if (tga-+header.color_map_entry_size '= 24) return(-1); 


These instructions check to see if the image is of type 1 (which is an 
uncompressed color-mapped file); whether the width is greater than 320 (in 
which case we cant use it on the mode 13h display); whether the height is greater 
than 200 (same problem); whether the number of bits per pixel is something 
other than 8; and whether the color map contains something other than 24-bit 
color descriptors. If the file passes all these checks — as the images that we're 
going to be using in this chapter will — we can begin processing the body of the 
file. First well load the ID string, in case the calling function is interested in 
doing something with it: | 

if (tga-+header. ID Length>0) f 

tga->ID=new charltga->header. 1b_lLength]; 


read(infile,tga->ID,tga->header.ID_length); 
} 


These instructions first check to see if the file actually contains an ID string by 
looking at the JD_fengrth held in the header, If this field is greater than 0, we call 
the C++ mew function, which allocates a chunk of memory equivalent to the 
value of the /D_length held and returns char * type pointer to the chunk. We 
then read the 1D string into this chunk of memory with the read) function. 

Before we can load the color map, we must allocate a 768-byte section of 
memory to store it in: 


if ((tga->color_map=new unsigned char€3*254))==NULL) 
return(-1); 


If the memory allocation fails, we return to the calling function with an error 
code. (The expression 3*256 is used instead of 768 to remind us that were 
loading 256 color descriptors that are each 3 bytes long — and because I find it 
easier to remember the number 256, which is commonly found in computer 
programs, than to remember the number 768.) Otherwise, we proceed to load 
the color map, translating it as we do so into a format acceptable to the VGA 
256-color palette-setting function: 
for (int entry=0; entry<256; entryt+) { 
for Cint color=2; coler>=0; -<-color) f 
read(infile,&(tga->color_mapLentry*3+color]),1); 
tga->color_maplentry*3+color] >>= 2; 
} 
} 


Exactly what sort of translation are we performing here? A VGA color descriptor 
consists of three values in the range 0 to 63, one each for the red, blue, and green 
intensities of the color. Only 6 bits are necessary to store values in this range. So, 
although we allot an 8-bit byte for each of these values when we pass them to the 
VGA 256-color palette-setting function, the two leftmost bits of those values 
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arent used. The Targa color descriptors, by contrast, are values in the range 0) to 
255, so they use all 8 bits of the bytes in the descripror. To translate them to 
VGA descriptors, we must shift the binary digits of these values two positions to 
the right, using the C/C++ => operator. (Actually, we use the >>= operator, which 
shifts the values and reassigns them to the variables in which they were already 
contained.) In addition, the Targa color descriptor values are in the order red, 
green, blue, while the VGA color descriptors should be in the order blue, green, 
red. Therefore we have to reverse the order of the descriptors as we load them 
into the array. That's why the for() loop that loads the three color descriptor 
values counts the index variable calor backward from 2 to 0, storing the values in 
the reverse order from that in which they are read from the disk. 

Since the image data is already stored in exactly the format we need for a 
mode 13h bitmap, loading the image is a simple matter of calculating the 
number of bytes it contains (by multiplying the smage_wiadth held of the header 
by the image_height held), allocating memory for the bitmap array, and reading 
the bitmap data from the disk into the array: 
unsigned int image_size=tga->header. image_width 

* tga->header. image_height; 
if (Ctga->image=new unsigned charlLimage_sizeJ])==NULL) 

return(=1); 
read(intile,tga-> image, image_size); 


Our job is now complete, so we close the Targa file and return to the calling 
function with a return value of 0, indicating that no errors occurred: 


closelinfile); 
return(O) >; 


The loadTGAQ Function 
The complete text of the feadTGA() function appears in Listing 4-2. 





Listing 4-2 The loadTGAQ function 


static int infile; // Handle for Targa file 


int LoadTGAtchar far *filename,tga_struct *tga) 

‘/ Loads an 88-bit uncompressed Targa file into @ structure of type 
// toa_struct 

{ 


‘/ Open file, abort if net found: 
if (Cintile=open(filename,0 BINARY) )==-1) return(-1); 


CORR ne niga petite 
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cmurye ried Jee Preps ier 
ff Set file pointer at start of file: 
Lseek(infile,OL,SEEK SET); 


/f Read header into header field: 
readlinfile,&(tga->header),sizeof(tga_header)); 


// Is this an uncompressed color-mapped image? If not, abort: 
if (tga->header.image_type '= 1) return(=1); 


ff Is the image wider than 320 pixels? If so, abort: 
if (tqa->header. image width> 320) returnt{-1); 


/f Is the image taller than 200 pixels? If so, abort: 
if (tga->header.image_height > 200) return(-1); 


ff Is it an 8-bit image? If not, abort: 
if (tga->header.bits_per_pixel '= 8) return(=1); 


// Does it have a 24-bit palette? If not, abort: 
if (tga->header.color_map_entry_size '= 24) returnt-1); 


ff If there's an ID string, load it: 
if (tga->header.ID Length>0) f 
tga->ID=new charltga->header.ID_LengthJ; 
read(inftile,tga->I0,tga->header.Ib length); 
} 
else tga->ID=0 
ff Allocate memory for palette, abort if not available: 
if ((tga->color_map=new unsigned charl3*256])==NULL) f{ 
if (tga->ID) delete toga->ID; 
return(-1); 
} 
// Load palette, translate for VGA: 
for Cint entry=0; entry<256; entry++) f 
for Cint color=2; color>=0; --color) ¢f 
read(infile,&(tga->color_mapLentry*3+color]),1); 
tga->color_maplentry*3+color] >>= 2; 
} 
} 


/f Calculate size of image in bytes: 
unsigned int image_size=tga—>header .image_width 
* tga—>header. image_height; 


/f Allocate memory for image, abort if not available: f 

delete tga->color_map; 

if (tga->ID) delete tga->ID; 

if ((tga->image=new unsigned charLimage_sizeJ)==NULL) 
return(-1l); 

} 


// Load image from file: 
read(infile,tga->image,image_size); 


] 
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ff Close file: 
closeCinfile); 


f/f Return without error: 
return(O); 


An 8-Bit Targa Display Program 


To demonstrate these functions (and, not incidentally, create a utility that will be 
useful throughout the remainder of this chapter), lets write a program called 
TGASHOW char will read 8-bit uncompressed Targa hles from the disk and 
display them in mode 13h, Such a program will need to include the TARGA.H 
header file at the beginning of any modules that reference the Targa loader 
functions, and should incorporate TARGA.CPP as part of the project fle or 
makehle used to construct the final code. Well keep our program simple by 
putting all the unique code not already incorporated elsewhere in one of our 
support modules in a single mara() function. This function will begin with the 
usual yarn) header, but will reference the standard C/C++ argument parameters 
so that the user will be able to pass the function the name of a Targa file from the 
command line: 

void maintint arge,char *argv0]) 


In case youre not familiar with the argument parameters, the integer 
parameter arge will automatically be set equal to the number of arguments (that 
15, strings of characters separated by blank spaces} that the Lser types On the 
command line when the program is invoked, including the name of the program 
itself. Thus argc will always be equal to at least 1. We want the user to be able to 
invoke the program with the name of a Targa hle as an argument, like this: 


tgashow image.tga 


So arge should be equal to 2 when the main function begins, since there should 
be two arguments on the command line (counting the name of che program). 
Well check for this at the beginning of the main() function and abort the 
program with an error code if the wrong number of arguments is found: 
if Carge!=2) { // Are there 2 arguments on command Line? 

puts("Wrong number of arguments. \n"); 


exit(-1); 
} 


The other argument parameter, “ergw//, is an array of pointers to the actual 
character strings that make up the arguments typed on the command line. The 
frst element of the array, argv /0/, always points to the name of the program itself, 
If you ever write a program that needs to know what name it was invoked under, 
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this is the best way to obtain that information. For our Targa-viewing program, 
we ll use the second element of this array, which will be pointing to the name of 
the Targa file that the user wants to view. We can pass this array element to the 
load TGA) function like this: 


‘/ Load Targa file. Abort if not found: 
if (loadTGAtargvllJ,&tga)) exitt1); 


You ll recall that the 4aa@7 GA) function returns a value of O if it’s successful in 
loading the file, -1 if it isnt. Here we simply look for a non-zero value (allowing 
us to expand our repertoire of error codes at a later date if we wish) and abort to 
DOS if one is found. The exe) function returns an error code of 1 to DOS, 
which can be detected by a batch file if one is used to invoke the TGASHOW 
program. The parameter fgz to which we pass the load 7TGA() function a pointer 
is a variable of type tea_struct, defned earlier in the program like this: 


tga_struct toa; 


Now that the Targa file has presumably been loaded, we can set mode 13h, 
clear the screen, and establish a pointer to video memory exactly as weve been 
doing in earlier programs (so we wont bother to detail the procedure here). The 
palette can be set to the color map from the Targa file using our set_palette() 
function, like this: 


‘f Set palette to Targa color map: 
setpalette(tga.color_map); 


The image itself can be copied directly from the tea.tmage held into video 
memory, with the aid of our usual screen pointer. However, we must take into 
account the possibilicy that the Targa image will be smaller than the 320 by 200 
mode 13h screen (as all of the Targa images we use in this chapter will be), The 
information about the size of the image is contained in the tmage_width and 
image_beight felds of the header structure, which contain the width and height 
of the image in pixels, We can use these as the limiting values of a pair of nested 
fort) loops, which will work their way across the image in the x and y dimensions, 
copying pixels as they go: 

‘/ Copy image to mode 13h display: 
for (int y=0; y<tga.header.image_ height; yt+) { 

for (int x=0; x<tga.header.image_width; x++) f 

screenLy*320+xJ=tga.imagely*tga.header. image_width+x]; 

} 

} 

The position at which to fetch each pixel from the Targa image array is calculated 
by multiplying the y position of the pixel by the width of the image and adding 
in the x position. The position at which to place the pixel on the mode 13h 
display is similarly calculated by multiplying the y position of the pixel by the 
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width of the screen (320) and adding in the x position. This will cause images 
smaller than 320 by 200 to appear in the upper-left corner of the display. Savvy 
programmers will note that this is a rather slow method of copying data — it 
wouldn't be difficult to come up with a faster technique — but time isn't exactly 
of the essence in this program. 


Tne TGASHOW Program 
The complete text of TGASHOW.CPP appears in Listing 4-3. 





Listing 4-3 The TGASHOW.CPP program 


// TGASHOW. CPP Version 1.0 

ff Display a 256-color Targa image on the mode 13h screen 
ff 

‘f/ Written by Christopher Lampton 

/f for Gardens of Imagination (Waite Group Press) 


Hinckude <stdio.h> 
Ainclude <dos.h> 
RFinclude <conio.h> 
#include <stdlib.h> 
Hinclude "“screen.h" 
Finclude “targa.h" 


tga_struct tga; 


¥VOId maintint arge,char *argvlJ) 
{ 
if Carge'=2) { // Are there 2 arguments on command Line? 
puts("Wrong number of arguments. \n"}; 
exit(=-1); 
} 


‘/ Load Targa file. Abort if not found: 
if CloadTGACargv[11,8tga)) exit(1); 


‘/ Create pointer to video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


if Save previous video mode: 
int oldmode=*Cint *)MK_FP(Ox40,0x49); 


‘?/ Put display in mode 13h: 
setmode(Qx13); 


‘/ Clear display: 
cls(scre en); CORN on next page 
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f/ Set palette to Targa color map: 
setpalette(tga.color map); 


‘/ Copy image to mode 13h display: 
for Cint y=0; y<tga.header.image_height; y++) { 
for Cint w=0; x<tga.header.image width; x++) { 
screenly*320¢xJ=tga. imagely*tga. header. image width+x J; 
+ 
} 


‘/ Pause until user presses a key: 
while ('kbhit¢)); 


‘/ Release memory 

delete tga. image; 

delete taa.color_map; 

if (tga.ID) delete tga.ID; 


if Restore old video mode: 
setmode(oldmode) ; 


Theresa copy at this program on the disk that accompanies this book. To mive 
it a test run, (2D to the subdirectory called BITMAP in the directory where you 
placed the files from this book. Then type the following on the command line: 
tgashow testmaze.tga 
A 160 by 100 image will appear in the upper-left corner of the mode 13h display. 
The image, which you can see reproduced here in Figure 4]. is an example of 
the maze graphics that we ll be developing in this chapter. More about this later. 





Figure 4-1 The TESTMAZE TOA image, a5 
displayed by the TOASHOW program. This 
is a sample of the maze graphics that 
we'll be developing later in this chapter 
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The PCX File Format 


Before we talk about using predefined bitmaps in animated maze games, we need 
to discuss one more file format. Although well be using the larga file format for 
easy compatibility with POVRAY and PicLab, were going to use the PCX format 
in all cases where a Targa file isn't strictly necessary. One reason for this is that the 
PCX formar includes data compression, allowing us to store the bitmap data in a 
smaller AMOUNT af Space. With state-of-the-art COMpPuter Pal ITIC ss now taking up rs 
much as 35 megabytes of hard drive real estate, the users of our games will thank 
us for conserving as much of their disk space as we can. (At least, theyll be a lirtle 
less angry at us if we don't wipe out those last few bytes that theyd intended to 
devote to spreadsheet data.) Another reason for using PCX files is that many 
paint programs, such as Deluxe Paint, will create fles in this format. 

The PCX format, like the Targa format, begins with a hle header describing 
the image stored in the file. Listing 4-4 shows the declaration for the header 
format structure, which we'll place in the file PCX.H. 





Listing 4-4 The PCX_HEADER structure 


struct pex_header f 


char manufacturer; // Always set to 0 

char version; ff Always 5 for 256-color files 

char encoding; ff Always set to 1 

char bits_per_pixel; // Should be 8 for 254<color files 

int xmin,¥min; ‘/ Coordinates for top Left corner 

int x=max, ymax; ff Coordinates for bottom right corner 
int hres; /f Horizontal resolution of image 

int wres; // Vertical resolution of image 


char palette léL4éJ; ff EGA palette; not used for 
‘f/f 256<color files 


char reserved; f/f Reserved for future use 
char color_planes; ff Color planes 
int bytes_per_line; // Number of bytes in 1 Line of 
ff pixels 
int palette_type; ‘/ Should be 2 for color palette 
char filler(58); ‘/ Nothing but junk 
}; 


Several of these fields correspond to the ones that we found of interest in the 
Targa header, though it isnt always obvious which ones, Oddly, there are no 
fields that correspond precisely to the #mage_wialth and imuage_height felds in the 
Targa header. Fortunately, this information can be caleulated from the 
information in the header like this: 


cay 
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int image_width = pex.header.xmax - pex.header.xmin +1; 
Int image height = pex.header.ymax - pex.header.ymin +1; 


where pex is a variable of type pex_struct. The filler feld at the bottom of the 
structure contains no valid data ar all, having apparently been included to bulk 
the structure out to an even 128 bytes, It's conceivable that this portion of the 
header will be used in future versions of the PCX standard, bur for now it can be 
safely ignored. 

The dehnition for our PCX structure, which is also included in PCX.H, is 
shown in Listing 4-5. 






=a Listing 4-5 The PCX_STRUCT structure 


struct pex_struct f 


pex_header header; /f Structure for halding the PCxX 
ff header 
unsigned char far “image; ff Pointer to a buffer holding 


‘/ the 64,000=<byte bitmap 
unsigned char palettelS*256]; // Array holding the ?é8- 
ff byte palette 
}; 


Aside from the PCX header, the PCX structure contains pointers to a char 
array containing the PCA image bitmap and a second char array containing the 
color descriptors in the palette, These two portions of the PCX hile — the image 
and the palette — follow immediately after the header. 


Run-Lengthn Encoding 

The PCX image is not stored in the PCX file as a straightforward bitmap, the 
way the uncompressed Targa image was. Rather, it is stored in compressed 
format. The type of compression used in PCX files is known as run-length 
encoding, or RLE for short. 

Run-length encoding is not a specific method of bitmap compression, but a 
generic term for a whole battery of data compression techniques. What all of 
these techniques have in common is that they store bytes in terms of runs. A run 
is a sequence of bytes thar all have the same value. This occurs commonly in 
bitmaps, where several pixels of the same color often appear in a row. In an 
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uncompressed 256-color bitmap, these rows of identically colored pixels are 
stored as runs of bytes representing the pixels. If there are 30 pixels in a row, all in 
palette color 117, then the bitmap will contain 30 bytes tn a row with a value of 
117. 

This is — quite literally — redundant. If you've seen one pixel with a value of 
117, then you've seen them all — and we dont need to store them all. Instead of 
storing 30 sequential bytes all with a value of 117, we can store the number 30 
followed by the number 117. Such a pair of numbers is called a run-length pair; 
the first number in such a pair always gives the number of bytes in the run and 
the second number gives the numerical value of those bytes. Storing a run of 30 
bytes in this manner would save us 28 bytes of storage, which ts well worth the 
effort if disk space is at a premium (which it usually is). 

When there are several bytes in a row with different values, this sort of run- 
length encoding can be quite inefhcient. Each byte would need to be stored as a 
run | byte long — thar is, as a run-length pair in which the first byte is a 1 and 
the second byte is the original value — which would double the storage required 
for those bytes. The ideal run-length scheme would include a way of turning 
RLE on when it’s needed and off when it isnt. 

The PCX RLE scheme does this by letting byte values in the range 192 
though 255 represent run-length values in the range 0 to 63. When a byte in this 
range is detected, the run-length decoder — the program that decompresses the 
RLE-encoded data — subtracts 192 from it and repeats the following byte value 
that many times. For instance, if the number 207 is encountered followed by the 
number 16, the decoder translates this into a run of 15 (207 minus 192) bytes 
with a value of 16, like this: 


16,16,16,16,16,16,16,16,16,16,16,16,16,16,16 


How does the PCA RLE scheme encode individual values in the range 192 to 
255 so that they wont be mistaken for run-length values? Alas, it must encode 
them as runs of a single byte in length — thar is, as the number 193 followed by 
the value to be encoded. For instance, an individual byte with a value of 239 
would be encoded as the number 193 followed by the number 239. This is a Haw 
in the PCX scheme that prevents it from achieving the maximum possible run- 
length compression — all those extra run-length values make the data larger than 
it has to be — but doesnt interfere in any way with the decoding of the data. In 
fact, it makes decoding simpler because we can decode these single-byte runs the 
same way that all other runs are encoded. 
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The loadPCx() Function 

To decompress an RLE-encoded PCX bitmap, we're going to write a function 

called foadPCA(). Because the RLE-encoding makes the PCX file format a bit 

more complicated than the uncompressed Targa format, we'll give this function a 

pair of subsidiary functions that it can call to load the image and the palette. 

We'll call these subsidiary functions fodel_image() and loaed_palette(), respectively. 
The prototype for the foadPCX() function looks like this: 


int LoadPCxX(char far *filename,pex_struct *pcx) 


The parameters are essentially the same as the ones passed to the load TGA() 
function that we described earlier in this chapter. The flename parameter is a 
pointer to an array of type char containing the pathname of the PCX file to be 
viewed, and the pex parameter is a pointer to a structure of type pex_struct into 
which will be placed the file data. 

We then proceed to open the fle and read the header data into the pex 
structure, exactly as we did in the faaa TGA) function: 
if (Cinfilesopen(filename,O_BINARY))===1) return(=1); 


Lseek(intile,OL,SEEK_SET); 
read(infile,&(pcex—->header),sizeofipcx header)); 


Now that we have the header data in memory, we check to see if the file 
contains a 320 by 200 or smaller image. If it doesnt, we return to the calling 
function with an error code: 


if (pex->header.xmax — pex->header.xmint] > 320) return{-1); 
if (pex->header.ymax — pex<>header.ymintl > 200) return(-1); 


We also check to make sure that the PCX fle is in Version 5 format, since this 
is the only type of PCX file that can store a 256-color image: 


if (pex->header.version != 5) return(-1); 


If all checks out, we call the foad_image() and load_palette() functions, close 
the file, and return to the calling function without an error code: 
if (Load _imagefinfile,pex)) returnt—-1); 
Load paletteCinfile,pcx}; 
closeCinfile); 
return(0); 


Note that we abort with an error code if the /oad_image() function fails, but dont 
bother to check for an error code from foad_palette(). That's because the 
load _palette() function doesn't return error codes, as youll see in a moment. 

The complete text of the feadPCAS) function appears in Listing 4-6, 
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Listing 4-6 The loadPCxXU) function 


static int infile; 


int lLoadPCxX(char far *filename,pcx_ struct *pex)? 
{ 
if (Cinfile=open( filename,0 BINARY) )==<-1) return(=1); 
lseek( infile,OL,SEEK_SET): 
read(infile,&(pcex->header),sizeof(pcex_header)); 
if (ocx->header.xmax -— pcox->header.xmintl > 320) return(-1); 
if (pex->header. ymax - pex->header.ymin¢1] > 200) return(-1); 
if (pcx=->header.version '= 5) return(-1); 
if (load_image(infile,pex)) return(-1); 
load palette(infile,pecx); 
close(infile); 
return(Q): 
} 


The load_image() Function 


The foad_tmage() function is rather complex, since it must decode the run-length 
encoding scheme used to encode PCX birmaps. Basically, it operates in 
rwo modes, identihed by the current value of the integer variable mode. This 
variable can take either of two values, defined at the head of the function as 
RUN_MODE and BYTE_MODE. When in BYTE_MODE, the foaed_tmage( 
function reads the next byte from the PCX file and checks to see if its in the 
range 192 to 255. If it isn’t in that range, it is pixel dara and the function simply 
outputs the value of the byte to the buffer that holds the decoded bitmap, If ir is 
in that range, the function subtracts 192 from the value, sets the integer variable 
bytecount equal to the result, fetches the next value from the file and stores it in 
the integer variable ourbyte, and sets the mode variable to RUN_MODE, While 
in RUN_MODE, the function repeatedly outputs the value of outbyte to the 
decoding buffer until Syrecount has been decremented to 0, thus decompressing 
the run of bytes. 
Heres the prototype for the /oad_smage() function: 


int Load_imagetint pexfile,pex struct *pcx); 


The first parameter, pevjile, is the handle of the PCX hile as returned by the apen() 
function. The second parameter, pex, is the same pointer to the pex_struct 
variable that was passed to /oadPCA() by the calling function. The complete text 
of the load_image() function appears in Listing 4-7. 
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“i! Listing 4-7 The load_imaget) function 


int lLoad_image(int pexfile,pex struct *pcx) 
/*f Decompress bitmap and store in buffer 


{ 
// Symbolic constants for encoding modes, with 
// > BYTEMODE representing uncompressed byte mode 
// and RUNMODE representing run-Length encoding mode: 
canst int BYTEMODE=0, RUNMODE=1; 


// Butter for data read from disk: 

const int BUFLEN=5*1024; 

int mode=BYTEMODE; // Current encoding mode being used, 
ff initially set to BYTEMODE 

int readlen; // Number of characters read from file 

static unsigned char outbyte; // Next byte for buffer 

static unsigned char bytecount; // Counter for runs 

static unsigned char buffterLBUFLENJ; // Disk read buffer 


/f Calculate size of image: 

int image_width=pex->header.xmax — pcx->header.xmin + 1; 
int Image_height=pcx-=header.ymax — pex->header.ymin + 1; 
Long image_size=(Long)image_width * image_height; 


ff Allocate memory for bitmap buffer and return —1 if 

/f oan error occurs: 

if ((pex=->image=new unsigned charlimage_sizeJ)==NULL) 
return(-1); 

int bufptr=0; // Point to start of buffer 

readlen=0; ‘/ Zero characters read so tar 


// Create pointer to start of image: 
unsigned char *image_ptr=pcx-> image; 


// Loop for entire Length of bitmap buffer: 
for (long 1=0; i<image_size; i++) 
if (mode==BYTEMODE) ¢ ff If we're in individual byte 
‘i mode... 
if (bufptr==readlen) { // If past end of buffer... 
bufptr=0; ff Point to start 


‘/ Read more bytes from file into buffer; 
// 7% no more bytes Left, break out of Loop 
if ((readlen=read(pexfile,buffer,BUFLEN))==0) 


break; 
} 
outbyte=buf ferlbufptr++]; // Next byte of bitmap 
if Coutbyte>Oxbf) ¢ ff If run-lLength flag... 
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ff Calculate number of bytes in run: 

bytecount = Cint)(CintJoutbyte & Ox3f); 

1f (bufptr>==readlen) { // If past end of buffer 
bufptr=0; ff Point to start 


ff Read more bytes from file into buffer; 
ff 4f no more bytes left, Break out of Loop 
if (Creadlen=read(pexfile,buffer,BUFLEN) )==0) 
break; 
} 
outbyte=butferLbutfptr++]; // Next byte of bitmap 


ff Switch to run-Length mode: 
if (—-bytecount > 0) mode = RUNMODE; 
} 
} 


ff Switch to individual byte mode: 
else if (--bytecount == 0} mode=BYTEMODE; 


// Add next byte to bitmap buffer: 
*image ptr+t+=outbyte; 
} 
return (0); 
} 


The load_paletteQ) Function 


The f/aaad_patlette() function is much simpler. In fact, it's pretty much tdentical to 
the code We used for loading the color Map from cl Targa hile, though weve put it 
in a separate function for consistency with the /oad_fmagel) function. The text of 
the Joad_palette() function is in Listing 4-8. 





Listing 4-8 The load_paletted) function 


void Load_paletteCint pexfile,pex_struct *pex) 
{ 
Lseek(pexfile,-768L,SEERK_END) ; 
read(pcxfile,pcx->palette,3*256) ; 
for Cint 1=0; i<256; i++) 
for Cint j=0; j<35; j++) 
pcox=>palettel1*3+}J=pex->paletteli*3+j 1>>2; 


There are two major differences between the palette loading code for the PCX 
hles and that for the Targa files. Before we can load the PCX palette, we must 
move the DOS file pointer to a position 768 bytes from the end of the file, since 
the PCX palette isn't guaranteed to follow immediately after the bitmap. 


— a F 
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(Generally, there is a single 0 byte between the bitmap and the palette, and we 
could probably get away with simply skipping this byte. However, to play tt safe, 
we position the file poincer relative to the end of the file, a technique that should 
work with all 256-color PCX files.) The other difference is that the 3 bytes of the 
color descriptors are in the same blue, green, red order required by the VGA 256- 
color palette setting function, so we dont need to step through them backwards 
as we did when loading the Targa color map. 


The PCXSHOW Program 


As with our Targa-loading function, well demonstrate the PCX loader by writing a 
short program to display 256-color PCX images on the mode 13h display. This 
program, like the Targa display program, will only work with 256-color images of 
320 by 200 or lower resolution. The text of the program PCASHOW.CPP appears 
in Listing 4-9. Because its essentially identical to the TGASHOW program 
described earlier, no detailed explanations of its inner workings are needed. 





Listing 4-9 The PCXSHOW program 


‘i PCXSHOW.CPP Version 1.1 

‘/ Display a PCX image on the mode 13h screen 

fi 

‘f/f Written by Christopher Lampton 

fi for GARDENS OF IMAGINATION (Waite Group Press) 


finclude <stdio.h> 
Finclude <dos.h> 
#include <conio.h> 
finclude <stdlib.h> 
Finclude “screen.h" 
finclude “pex.h" 


pcx_struct pex; 
void maintint argc,char *argvLl]) 
{ 


if Carge!=2) { // Are there 2 arguments on command Line? 


puts("Wrong number of arguments. \n"); 
exitt-1l); 


, 


// Create pointer to video memory: 
char far *screen=(char far *)MK_FP(Oxal00,0); 
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‘/ Save previous video mode: 
int oldmode=*(int *)MK_FPCOx40,0”49) : 


/f Put display in mode 13h: 
setmode(Ox13); 


‘/ Clear display: 
cls(sc¢reen); 


if C(loadPCXtargvlL11],ipex)) ¢ 
setmode(oldmode); 
exittl); 
} 
int image _width=pex.header.xmax — pex.header.xmin + T; 
int image_height=pcx.header.ymax - pex.header.ymin + 1; 
Long image_size=(Long)image_width * image_height; 
setpalette(pcx.palette); 
for Cint y=0; y*image_ height; yr) 4 
for (int x=0; =x<image_width; x++) 4 
screenly*320+xJ=pcx. imagely* image _width+xJ]; 
} 
} 


while ('kbhitt)); 


‘/ Release memory 
delete pcx. image; 


‘/ Restore old video mode: 
setmodeloldmode) ; 


This program 1s available on the included disk as PCXSHOW. EXE. 


Building a Bitmapped Maze 


Now that we have the ability to store predesigned bitmaps on the disk and load 
them into the computers memory, we can use this capability to construct fully 
bitmapped three-dimensional images of the interior of a maze on the mode 13h 
display. This is not a trivial task, however. Before we can accomplish it, well need 
to solve several technical problems that we ignored in creating the wireframe 
maze code in the previous two chapters. 

One problem we rather obviously ignored was realism — or, more 
importantly, the lack thereof. To give you an idea of the sort of realism were 
shooting for in our bitmapped maze engine, look at the screen shot in Figure 4-2, 
taken from a recent entry in the Wizardry series of CRPGs. This image is far 
more realistic than the wireframe graphics in the first hve Wizardry games, which 
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we emulated with our wireframe maze program. Or go back and look at Figure 
4-1, the one we used to demonstrate the TGASHOW program, which shows you 
some of the bitmaps that well be using. 

Even better, go back into the BITMAP directory and use TGASHOW — or 
any other graphics display utilicy you own that can display 8-bit Targa files — to 
take another look at TESTMAZE.TGA. Quite a difference from the graphics in 
the last chapter, right? Instead of black lines on a white background, we now see 
fully detailed walls, a reflective tile floor, and a blue sky with putty white clouds 
Hoating in it. In fact, this image is so detailed that you might wonder how we're 
going ta cram all of those pixels into place fast enough to allow the user to walk 
around “inside” the maze in real ime. Uhe solution is to draw all of the pieces of 
the image in advance, then mix and match those pieces while the program is 
running to construct a picture of the way the maze appears from whatever 
location and direction the viewer ts looking ar it from. 

And to do that, well curn to the Persistence of Vision ray tracer for help. 


Ray Tracing the Maze 


ve chosen to use the POV ray tracer to generate the maze images tn this chapter for 
rwo reasons. The first is that its a very good ray tracer. The second is that irs free. 

If youre not already familiar with POV, that second statement may catch you 
off guard. Free? Who gives away pertectly decent pieces of software — especially 
software as complex and useful as a ray tracer — for free? In this case, the 





Figure 4-2? A scene from Crusaders of the Dark Savant, the 
seventh entry in the Wizardry senes. The bitmapped maze 
graphics aré.a considerable improvement over the wireframe 


graonics in the first hve games of the series 
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samaritans wha Are giving away’ the software are a Proup of PrOopraniniers who 
make their home on the CompuServe Information Service and who write 
eraphics-related code for the sheer fun of it, not to mention the joy of providing 
useful, free software to people who have a need for it (or who just want to play 
around wath it}. Because it's available for free, YOu might Want to Fret d COPY of 
your own and use it to generate additional graphics for the maze program in this 
chapter (or for maze programs that youve written yourself). Take a look in 
Appendix A of this book for more detailed instructions on how to get your hands 
on POWVRAY and how to use it to generate maze graphics for the program that 
we ll be creating in this chapter. 

In case youre not already familiar with the concept, a ray tracer is a program 
that takes a mathematical description of a scene — a description couched tn 
terms of certain standard shapes and the mathematical relationships berween 
them — and creates a picture of that scene as it would appear if it existed in the 
real world. (Actually, the images created by a ray tracer often seem mrore realistic 
than any you might see in the real world, filled with impossibly shiny surtaces 
and vivid textures. This makes ray tracing an excellent method of generating 
hyper- realistic computer game images.) It does this by tracing the paths of 
imaginary light rays as they bounce around the scene, eventually encountering 
the viewers eyes. We'll talk more about the mechanics of ray tracing in chapter 8, 
For now, well just use POWRAY as a turnkey application that can generate ray- 
traced images for us. 

We havent included POVRAY on the disk thar comes with this book, and you 
dont really need a copy of it in order to use the maze engine that we ll develop in 
this chapter, because I've already created a set of images that are included on the 
disk. However, you may want to obtain a copy anyway, so that you can use it to 
generate new maze graphics for the program in this chapter (or for maze 
programs that you write yourself). Once again, you should take a look ar 
Appendix A for details on how to do this. 


Nine Views of the Maze 


What sort of images do we want POVRAY to create? Well, the maze images that 
were going to construct (as you can see in the TESTMAZE.-TGA image) will 
consist of four primary elements: the floor, the sky, and the front and side walls 
of the “blocks” that make up the maze. Thus the images that we create with 
POVRAY will need to contain these four elements. The sky and floor will 
probably look pretty much the same in every image we construct of the interior 
of the maze, differing only in the way that they are obscured by the other nwo 
elements. It is the front and side views of the maze blocks thar will differ most 
significantly from one image to the next. So the main thing we need POVRAY to 
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do for us is to generate pictures of the fronts and sides of the maze blocks in all 
the possible ways in which they may appear in a scene. 

This may sound quite difficult, but in fact it only requires that we generate 
nine separate images. This will allow us to construct images of the maze as it 
appears out to hve squares in front of the viewer, counting the square in which 
the viewer is standing, (We can actually get by with even fewer images than this, 





fe 
-_ 





— 
Figure 4-3a-—e These five images, Figure 4-35 


generated by the POV ray tracer, depict 
the fronts of maze blocks a5 they appear 
Out to a distance of five squares in Front 
of the viewer 
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as well explain at the end of this chapter, bur for now we're going to tolerate 
some redundancy in the images in order to simplify our programming task.) 

The first five images that well generate with POVRAY will depict the fronts of 
the maze blocks as they appear at distances of one, owo, three, four, and five 
squares away from the viewer. These images appear in Figure 4-3. On the disk, 
we have given them the filenames FRONTI.TGA through FRONTS.TGA. You 
can view them using TGASHOW or any other file viewer that can display 8-bit 
Targa files. 

The remaining four images depict the left and right sides of the maze blocks as 
they appear at distances of one, two, three, and four squares to cach side of the 
viewer, Its not necessary to include images of the block sides as they appear at a 
distance of five squares from the viewer, since theyll no longer be visible on the 
periphery of the tmage at that distance. These images appear in Figure 4-4 and 


on disk as SIDEL.TGA through SIDE4. TGA. 









Figure 4-da-—d These four images depict 
the left and rant sides of maze blocks as 
they appear at distances of one, two. 
three, and four squares to each side of 
the viewer 





Figure 4-4c Figure 4-4d 
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Slicing and Dicing the Maze 


Now that we have these images, what do we do with them? We chop them up 
and use them to construct individual “snapshots” of the maze. I like to think of 
this as the slice-and-dice method of maze generation. From these nine ray-traced 
images, we can slice and dice together a large number of composite images 
showing how different parts of the maze look when viewed from various angles. 
The trick is hguring out what parts of these images to slice and when to slice 
them. 

To that end, well create a d@ntwmaze() function that will operate essentially 
like the drawmaze() function that generated our wireframe maze. In fact, it will 
be possible to drop this function into a program nearly identical to the animated 
wireframe maze program in the last chapter. However, this function will be a 
great deal more complex than the wireframe maze-drawing function, not just 
because it will deal with bitmaps rather than lines — in fact, bitmaps are actually 
somewhat easier to put on the display than straight lines — but because we'll use 
It to render Thane complex VICWS of the maze. 

For instance, the wireframe maze-drawing function developed in chapter 2 
had difficulty with any parts of the maze that were not along the line of squares 
proceeding away directly in front of the viewer. And it couldn't handle situations 
in which four empty squares wete arranged together in a block. It could draw 
maze images analogous to the bitmapped image in Figure 4-5, bur not like the 
ones in Figure 4-6. We could get away with that sort of approximation of reality 
in a wireframe maze program because wireframe mazes are inherently unrealistic, 
If holes appeared in the image where hallways were supposed to be, it wasn't 
especially bothersome. Ina bitmapped Masc Prosranm, however, Wwe cant tolerate 
such lapses of realism. 

To get around these problems, we'll use a recursive maze-drawing function. 
What's a recursive function? It's a function that calls itself. If you're not familiar 
with the principles of recursive programming, this might sound rather pointless, 
Why would we write a function that calls itself? As I describe the algorithm 
behind the function, though, | suspect you'll begin to see;why recursion is just 
the ticket for producing a realistic maze. 


The Maze-Drawing Algorithm 

The maze-drawing function will be based on the simple concept thar the three- 
dimensional view of the maze, which we'll be drawing in a rectangular window 
on the display, divides up neatly into three portions. Lets take a closer look at 
how it does so. 
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Figure 4-5 We could draw this image using essentially thé same 
echniques we used fo create the wireframe maze graphics in 


chapters 2? and 3, iF we substituted bitmaps tor white lines 


As in the last owo chapters, the maze will be defined as a matrix of squares 
similar to a checkerboard. Each of these squares is either empty or contains a 
solid block, presumably carved from some impassable (and visually opaque) 
substance. At any given moment, the viewer will be standing in the middle of 





one of these squares, looking in one of the cardina compass directions — that ts. 
toward one of the sides of the current square. We can theretore visualize the 


three-dimensional maze view that we'll be drawing aon the screen as consisting ot 





Figures 4-6 a—b The techniques we used Figure 4-6b 
to créate the witeffame Maze graphics in 

chapters 4 and 3 would not be adequate 

to create images like these, even with the 

SUDStITUtON of bitmaps for white lines 
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MIDDLE =O CRG 


Figure 4-7 The maze view window divides neatly into bert, right, and middle views 


three parts: the view to the left of the current square, the view to the right, and 
the view straight down the middle. Figure 4-7 shows how the view window on 
the display divides up into these three views. 

Each of these three views looks across one of the three visible squares adjoining 
the current square. (There are actually four squares adjoining the current square, 
but the one to the rear of the viewer isn't visible, so we wont be concerned with it 
here.) If one of these squares contains a block, then the portion of the view 
window that looks across that square will be completely filled with the image of 
that block, or a section of that image. If the square to the left of the current 
square contains a block, for instance, the left portion of the view will be filled 
with an image of the right side of that block (see Figure 4-8). If the square to the 
tight contains a black, the right portion of the view will be filled with an image 
of the left side of that block (see Figure 4-9). And if the square in front of the 
current square contains a block, the middle portion of the view will be filled with 
an image of the front of that block (see Figure 4-10). Each of these images — of 
the left, right, and front sides of a maze block as seen at a distance of one square 
— are available tn one of the TGA fles that we created with the POV ray tracer. 
In this case the left and right images are in SIDEIL.TGA and the front image 1s 16 
FRONTI.TGA. 

[f all three of these squares contain blocks, then drawing the view will be a 
simple matter of slicing these images from the SIDE1.TGA and FRONT1,TGA 
files and dicing them into the appropriate portions of che view window. Figure 
4-11 shows what the resulting image would look like. Drawing this image 1s 
simply a matter of checking the squares to the left, right, and in front of the 
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Maze 








Figure 4-8 lf the squaré to the left oF the current square 
contains a block, the left portion of the wew will be filled 
With an image of the rant side of that biock 


Maze 





View 





Figure 4-9 |f the square to the right of the current 
square contains a block, the right portion of the view will 
be filled with an image of the left side of that block 
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View Solid Wall 





Figure 4-10 |f the square in front of the current square 
contains 2a block, the middie porton of the view will be 
filed with an image of the front of that block 





Figure 4-11 The view fram the current square if all three visible agjoining squares contain 
blacks 
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current square to see if they contain blocks. [f they do, the images of the blocks 
are copied from the TGA files (which we will have stored in memory previously, 
using the load TGA() fanction) into the appropriate positions on the display. 

But this is an unusually easy case to handle. In fact, it is the simplest image 
that our maze-drawing function will ever be called upon to render. What if one 
of the visible squares adjoining the current square is wef occupied by a block? 
What do we do then? Obviously, we dont draw the image of a block if there isn’t 
one there — but what do we draw in its place? We cant simply draw nothing; 
that would leave a gaping black hole in our drawing, which is inherently 
unrealistic. We might have been able to get away with this in our wireframe maze 
program, but such a lazy programming technique isnt adequate to the realism of 
a bitmapped maze. 

We could simply proceed to check to see if the squares on the other side of the 
adjoining square are occupied, then draw any blocks that we find there, but this 
is an awkward thing to do. There may be as many as three additional squares 
visible through each of the squares adjoining the current square and we'll need to 
search each of them to see if theyre occupied by blocks. And if they arent 
occupied by blocks, we'll need to search even further into the maze, looking for 
blocks to draw. 

lf were not careful, our drawmazel) function could become quite complicated. 
Fortunately, there's a fairly simple approach that we can take that will strip away 
much of the complexity. Each of the squares adjoining the current maze square 
presents almost exactly the ea TC visual problem that the current Aquare does — 
that is, each is bordered by three squares that could potentially contain visible 
blocks. (Once again, well ignore the fourth adjoining square, the one to the rear 
of the square currently under consideration. Although in many cases this square 
may be visible, the fact that we can see through ir tells us that ic isnt occupied by 
a block.) If we write a simple function that examines the current square (which 
we know to be empty because were standing in it) to see if its surrounded by any 
visible blocks (and which draws them if it finds them), that function can call 
itself recursively with slightly modihed parameters to examine any adjoining 
empty squares to see if they are in turn surrounded by vistble blocks. In other 
words, all we need to do is write a function to deal with a single square and let 
recursion handle the rest. 

This will present some technical problems, but they aren't difficult to solve. 
Well have to be sure that the function only draws those blocks that would be 
visible from the current position and that ic doesnt try to draw blocks that are off 
the left and right edges of the view window. However, this is a simple matter of 
passing a pair of parameters to the function telling it what the left and right 
limits of the current view actually are. Initially, these will be the left and 


GARDENS OF IMAGINATION 


right horizontal coordinates of the entire view window. (We'll measure these 
coordinates relative to the 160 by 100 pixel view window itself, so the left 
horizontal coordinate will initially be 0 and the right horizontal coordinate will be 
159.) But when the function calls itself recursively, these will become the left and 
right limits of the part of the view window covered by the square currently being 
examined. When the function calls itself to handle the square to the immediate 
left, for instance, it will pass itself the left and right coordinates of the portion of 
the view window that represents the left view, as we illustrated in Figure 4-8. 


The Bitmapped drawmaze() Function 


Now that we have at least some idea of how the maze-drawing function will work, 
let's write it. The prototype for the function looks like this: 


void drawmaze(int xshift,int yshift,int lview,int rview, 
char *screen); 


The first thing youre likely to notice is that there are a lot more parameters being 
passed to this version of the function than there were to the version that drew 
wireframe mazes. Bear in mind that this function is designed to work with only 
one square of the maze at a time; it will call itself recursively to deal with other 
squares in the maze. Thus the first two parameters, xshift and yshift, tell us how 
far the square currently being examined is from the square in which the viewer is 
standing. The first parameter, xshzft, tells us how far (in squares) this square is to 
the left of the viewer's square (with negative values representing positions to the 
right of the viewer's square). The second parameter, yshzft, tells us how far 
forward the square currently being examined is from the viewer's square. This 
value will always be positive, since we aren't interested in the unseen squares to 
the rear of the viewer's square. 

On the first call to the function, these values should both be 0, since the 
square in which the viewer is standing is always the first square that drawmaze() 
should examine. During recursive calls, the function will shift these parameters to 
the left, right, and front, if the squares in those directions are visible and no 
blocks are found in them. The /view and rview parameters represent the left and 
right horizontal coordinates of the screen window in which any visible blocks are 
to be drawn. Initially, these will be the same as the left and right horizontal 
coordinates of the view window — that is, 0 and 159 — but during recursive 
calls they will be repeatedly reduced to those sections of the view window that are 
visible through the square currently being examined. 

We don’t want the function to keep calling itself recursively forever; this could 
cause it to lock up in an endless loop. As a more practical matter, we dont want it 
to call itself to examine squares beyond the visibility limit inherent in our 
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prerendered TGA files. Since these files only show the sides of blocks up to five 
squares distant, we ll set the viewing distance as covering the viewers current 
square plus four additional squares. Well define this distance at the front of the 
program with the constant VIEW _LIMIT (which well set equal to 4) and begin 
the anzwmaze() function by checking to see if it has been reached: 

/f Return if we've reached the recursive Limit: 


if (Cabs(xshift) > VIEWLIMIT) || (absCyshift) > VIEW_LIMIT)) 
return; 


This will prevent the function from making further recursive calls to itself. In 
practice, we dont want this limit ever to be reached, since invoking this escape 
clause will leave a gaping black hole in the maze drawing, So we must be careful 
tO design Maecs in which the viewer Can never see more than four SQUAreS ahead 
in any direction. Later in this chapter, we'll suggest some ways to avoid — or at 
least make less restrictive — this limitation. (Note that this doesn't mean 
avoiding more than four squares in a row, but avoiding lines of sight that extend 
for more than four squares. Since lines of sight can go at an angle to the grid of 
squares, there will be situations where the corridor in front of the view extends 
for four OF fewer SOUATCS, burt | fifth aQuare IS nonetheless visible around d COPTMeCT, 
It may require some trial and error to Hind such situations and restructure the 
map of the maze to avoid them.) 

Now that we ve got that minor technicality out of the way, we can get down to 
the real work of the function, which ts to check the squares to the left, front, and 
right of the current square to see if they are occupied by blocks. Well break this 
into three separate tasks and check the square to the left first. We'll do this with 
the aid of the same data structures that we used in the last two chapters to define 
positions and movements within the maze. Youll recall that the viewers position 
is contained in the variables pos.x and pas.y, and that the viewer's orientation is 
contained in the variable dir. Because the meaning of such directions as left, 
right, and forward changes according to the viewers orientation, we also created 
three arrays — called Jef, right, and fortward — that defined the way in which the 
x and y coordinates within the maze change when we move in each of those 
directions. For instance, the variables /eft/O/.x. and Jeft/O/-y contain the changes in 
the x and y coordinates when our orientation is in direction 0 (which happens to 
be north) and we move to the lett. Similarly, the variables forward/2/.x and 
forward/2).y contain the changes in the x and y coordinares when our orientation 
is in direction 2 (south) and we move forward. 

We can use these data structures to calculate coordinates within the maze of 
the square currently being examined and assign those coordinates to the variables 
seand 5, like this: 


‘f/f Calculate coordinates of square to Left: 


‘at 


Ls oe cll 





GARDENS OF IMAGINATION 


int sx = pos.x + (xshift+l) * Leftidirl].x + yshift * forwardidirl.x; 
int sy = pos.y + (xshiftt+l) * Lefttdirld.y + yshift * forwardfdird.y; 


We multiply ss/ift by the left increment for the current position because sxshift 
represents movement to the left of the viewer's position and we multiply yshi/t by 
the forward increment because yshiff equals movement forward from the viewer's 
position (see Figure 4-12). 

We know that the parameters /view and refew represent the left and right 
limits of our current drawing window. Now we must calculate the limits of the 
lefthand portion of that window, the portion that represents the view ro the left 
of our current position. We'll store these limits in the integer variables vleft and 
wight, Calculating the left limit is easy, since it's the same as the left limit of our 
overall view window: 


vleft=lview; 


Calculating the right limit of the lefthand view is trickier — a Jor trickier. In 
fact, there's not really any way to calculate it at all, since we're working with 
predefined bitmaps and we must match our view to the positions of the blocks 
within those bitmaps; otherwise, they wont be drawn properly when we slice and 
dice our images together. So, in order to see where the right edge of the lefthand 
view is, we must look at the images created by POVRAY to see where it drew the 
edges of the block. 

If the square that we're currently examining is the one in which the viewer is 
standing, then the left portion of the view extends from horizontal coordinate 0 
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(the extreme left side of the view window) to horizontal coordinate 3%. (These 
coordinates are defined relative to the contents of the window, not the display in 
which the window will eventually be placed.) You can see this by looking at 
FRONT1.TGA. Although it’s hard to tell where one block ends and another 
begins by looking at the greenish granite walls of the maze, its possible to 
identify block boundaries by looking at the checkerboard patterns on the floor. 
Each maze square contains 16 checkers, arranged four on a side. The tour 
checkers aligned with the middle portion of the green wall define the block 
directly in front of the viewer. The block portions to the left and right of this 
define the positions of the nwo adjoining squares, If you count the pixels from the 
left edge of the view to the nght edge of the leftmost block, you'll find thar they 
extend from horizontal coordinate 0 to horizontal coordinate 39, as in Figure 
4-13. (Well, okay, youre probably not enthusiastic about sitting around counting 
pixels on the display, so [ve counted them for you using Deluxe Paint.) Similarly, 
the central portion of the view (corresponding to the extent of the block 
immediately in front of the viewer) extends from horizontal coordinate 40 
to horizontal coordinate 120 and the righthand portion of the view extends from 
horizontal coordinate 121 to horizontal coordinate 159. 

Burt these coordinates are only valid if were examining the square where the 
viewer Is standing, As the maze-drawing function moves recursively from square 
to square, the precise horizontal coordinates represented by the left, right, and 
center views will change. For instance, from the square to the immediate left of 


— 
= 
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Figure 4-13 The leftmost block in FRONT1.7GA extends across the image from horizontal 


position 0 to honzontal position 39 
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the current square, the entire view covers only the letthand portion of the display 
— that ts, the area from horizontal coordinate 0 to herizental coordinate 39. 
Within that portion, the lefthand portion of the view from that square only 
covers the segment of the view window from horizontal coordinate 0 to 
horizontal coordinate 7. (This is the extent of the leftmost block front in 
FRONT2.TGA.) The central portion of the view extends trom horizontal 
coordinate 8 to horizontal coordinate 39. And there is no righthand portion to 
the view from that square, since it would be outside the area that we can view 
through that square. 

Whew! How are we going to take care of all that in our recursive function? 
How can we determine where the lefthand, righthand, and central portions of 
the current view are in the view window? [he answer is surprisingly simple. We 
must treat the grid of maze squares radiating ourward in front of the view as a 
network of intersecting grid lines, as shown in Figure 4-14. All we need to worry 
about are the screen coordinates of the points at which these grid lines intersect, 
since these correspond to the segments of the view window taken up by the 
fronts and sides of the maze blocks. We can determine these by studying the 
TGA files produced by the ray tracer using a program like Deluxe Paint. Then we 
can encode them in a two-dimensional array that can be referenced by the 
drawmaze() function. Don't worry; you wont have to dig up a copy of Deluxe 
Paint and do this yourself, because I've already done it for you. Here's the 
resulting array: 


int matrixCVIEW_LIMIT+1ICVIEW_LIMIT*2+2J)=1 
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(160,160,160,160,121, 40, 0, O, 0, OF, 

(160,160,160,155,105, 56, 8, OQ, O, Of, 

{160,160,160,132, 98, 63, 29, O, O, OF, 

{160,160,147,121, 94, 47, 40, 14, O, Ot, 

{160,160,141,117, 93, 68, 44, 20, O, QO} 
7 


The first row of elements in this array corresponds to the grid line running 
horizontally in front of the viewer — that is, to the row of block fronts shown in 
the image PRONT1.1TGA. There are only two visible intersection points 
berween this grid line and the vertical grid lines running away from the viewer. 
These occur at horizontal coordinates 40 and 121 in the view window. We've 
placed those numbers in the center of the row and assigned the other intersection 
points horizontal coordinates corresponding vo the edge of the display, indicating 
that they are actually eff of the edge. The second row of elements corresponds to 
the horizontal row behind that row, equivalent to the row of block fronts shown 
in the image FRONT2.TGA. And so forth. The nwo middle elements of cach 
Altay correspond to the intersection points between these Pi and the POS ot 
block sides depicted in SIDE].TGA. The owo elements to each side of these 
correspond to the intersection points with the rows of block sides in 
SIDE2.TGA. And so forth. 

This gives us a relatively simple way of determining the current left portion of 
the display. We can do it like this: 
vright=matrixCyshiftiCxshift+ViIEW _LIMIT+1I; 


This gives us the position in the marrx// array corresponding to the grid 
intersection immediately forward and to the left of the square currently being 
examined. 

Its possible that the right edge that we've calculated in this manner will 
actually be farther to the right than the right edge of the viewing window passed 
ro us by the calling function. If so, the edge passed by the calling function takes 
priority over this edge; we must clip this edge to tr: 


if (vright=rview) vright=rview; 


After all of the above, the width of our new viewing window may be 0); this 
would be true, for instance, if we've recursed all the way past the left edge of the 
original view window, into that part of the grid where we've set all intersection 
points equal to either 0 or 160. So we calculate the width of the window: 


vwidth=vright-vleft; 
If the width isn’t 0, we proceed to check the square to the left of the current 


square — the one that’s visible through the left portion of the current view — to 
see if its occupied by a block: 
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if C(vwidth=0) ¢ 
if (mazeCsxJCsyl]) f 


If it is, we call a function called display_sfice() that takes a horizontal slice out of 
one of the TGA images and copies it to the video butter: 


display_slice(xshift+VIEW_LIMIT+1,vleft,vright,screen) > 
} 


Well look at the a@ispday_stice() function in a moment. The first parameter in the 
call is the number of the fle containing the desired slice, where FRONT1.TGA 
through FRONTS. TGA are 0 through 4 and SIDE].TGA through SIDE4.TGA 
are 5 through & Were drawing the block to the left of the current block, so we 
know thar well be drawing a side view. Thus the fle that we want to slice the 
image from is at least number 5, which is VIEW_LIMIT+1. (We use 
VIEW _LIMIT+1 to determine the number of the file rather than 5 so thar it will 
be easier to change the view limir at a later date, though we'll need to add 
additional bitmap files should we decide to do this.) We add to this the xshuft 
distance from the viewer's position, since this will deine how many squares away 
from the center the side that we wish to draw is and thus which TGA hle it will 
come from. The remaining three parameters define the left and right horizontal 
coordinates of the slice that we wish to draw and the address of the screen buffer 
we wish to draw it to. 

What if we don't find a block in the square to the left? Simple. We call the 
drawmaze() function recursively, shifting one square to the left, and start all over 
again: 

else drawmaze(xshiftt+1l,yshift,vleft,vright,screen) > 
} 


Now we just repeat this process for the central and rightmost portions of the 
view. Heres how we handle che center portion of the view: 


‘/ Get Left=-right extent of center part of view: 
vleft=matrixCyshiftJ0xshift+VIEwW_LIMIT+1J]; 
vright=matrixCyshiftiixshift+VIEW_LIMITI; 

if (vleft<elview) vleft=lview; 

if (vright=rview) vright=rview; 
wwidth=vright-vLleft; 


if (vwidth=0) ¢ 


// If the square directly ahead is occupied, 
‘/* draw front of cube: 
if (mazelCsxJCsyJ) 4 

display slice(yshift,vleft,vright,screen); 
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‘/ Else call function recursively to draw the view from 
ff next square forward: 
else drawmaze(xshift,yshift+l,vleft,vright,screen); 

I 


And we handle the rightmost portion of the view in a nearly identical manner: 


f/f Calculate coordinates of square to right: 
sx = pos.x + (xshift-1) * LefttCadiri.x + yshiftt * forwardldird.x; 
sy = pos.y * (xshift<-1) * Left€dirl.y + yshift * forward[dird.y; 


ff Get Left-right extent of right part of view: 
vleft=matrixCyshiftiixshift+VIEW_LIMITI; 

if (vleft<lview) vleft=lview; 

wright=rview; 

vwidth=vright=vleft; 


if Cywidth=0) ¢{ 


ff If the square to the right is occupied, 

// draw Left side of cube: 

if (mazelLsxJLsyJ) tf 
display_slice(VIEW_LIMIT+1-xshift,vleft,vright,screen); 

} 


ff Else call function recursively to draw the view from 


// next square to the right: 
else drawmaze(xshift—1,yshift,vleft,vright,screen) ; 


The complete text of the dnawmaze() function appears in Listing 4-10. 






Listing 4-10 The bitmapped drawmazel) function 


void drawmazeCint xshift,int yshift,int Lview,int rview,char “screen) 


‘f/f Recursive function to draw left, right and center walls for the 
‘f/f maze square at POS.X+ZSHIFT, POS.¥+YSHIFT, as viewed from POS.%, 
ff POS.Y, within the screen window bordered by horizontal coordinates 
‘/ LVIEW and RVIEW on the Left and right respectively. When called 
‘/ with XSHIFT and YSHIFT set to 0, draws entire maze as viewed 
‘f/f from POS.%,POS.¥ out to VIEW_LIMIT squares. 
{ 
int vleft,vright,vwidth; 


ff Return if we've reached the recursive Limit: 
if (Cabs(xshift) > VIEW_LIMIT) || Cabs€yshift) > VIEW_LIMIT)) 
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return; 





‘i Calculate coordinates of square to Left: 
int sx = pos.x + (xshift+l) * Left€dird.x + yshift * forwardldird.x; 
int sy = pos.y + (xshitt+l) * LeftCdird.y + yshift * forward[dirl.y; 


‘f Get Left=right extent of Left part of view: 
vleftt=lview; 
vright=matrixCyshiftJixshift+VIEW_LIMIT+11; 

if C(vright>=rview) vright=rview; 
vwidth=vright-vleft; 


if (vwidth=0) ¢ 


‘f If the square to the left is occupied, 

f/f draw right side of cube: 

if (mazeCsxJCsyl]) ¢{ 
display_slice(xshift+VIEW_LIMIT+1,vleft,vright,screen); 

} 


‘/ Else call function recursively to draw the view from 
/f next square to the Left: 
else drawmaze(xshift+l,yshift,vleft,vright,screen); 

} 


‘/ Calculate coordinates of square directly ahead: 
5x = pos.x + xshift * LeftCdirl.x + Cyshift+l) * forwardl[dirl].x; 
sy = pos.y + xshift * Leftldirj.y + (yshift+l) * forwardldird.y; 


‘f/f Get Left-right extent of center part of view: 
vleft=matrixCyshiftl[0xshift+vVIEw _LIMIT+11; 
vright=matrixCyshi ftilxshift+VIEW_LIMITI; 

if (vleft<lview) vleft=lview; 

if (vright=rview) vright=rview; 
vwidth=vright-vleft; 


if (vwidth=@) { 


if If the square directly ahead 15 occupied, 
‘/ draw front of cube: 
if (mazeCsxJ€syJ) ¢{ 

display slicetyshift,vleft,vright,screen); 
} 


// Else call function recursively to draw the view from 
ff next square forward: 
else drawmaze(xshift,yshift+l,vleft,vright,screen) ; 


‘/ Calculate coordinates of square to right: 
5x = pos.x + (xshift-1) * Leftidird.x + yshift * forward(dird.x; 
pos.y¥ + (xshift=-1) * leftCdirl.y + yshift * forward{dird.y; 


in 
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‘/ Get left-right extent of right part of view: 
vleft=matrixlyshiftILxshift+ViEW_LIMITI; 

if (vleft<lview) vlett=lview; 

vright=rview; 

vwidth=vright-vLeft; 


if (vwidth>=0) f 


ff If the square to the right 18 occupied, 
‘/ draw left side of cube: 
if (mazelsxJCsyl) f 
display _slice(VIEW_LIMIT+ l=<xshift,vleft,vright,screen) ; 
} 


ff Else call function recursively to draw the view from 
f/f next square to the right: 
else drawmaze(xshift-l,yshift,vleft,vright,screen); 


The draw_sliceQ) Function 

The text of the dnaw_sitce() function, which draws a vertical slice out of a 160 by 
100 bitmap stored in an array to the equivalent position in the 160 by 100 view 
window, appears in Listing 4-11. 






Listing 4-11 The draw_slice() function 


¥vold display_slicelint imagenum,int Leftx,int rightx,char far "sereen? 


‘/ Displays vertical slice of 160x100 bitmap from horizontal 
‘/ coordinate LEFTX to horizontal coordinate RIGHTX 
f 
for Cint y=0; y<100; y++) f 
for Cint x=lLeftx; x<(rightx+1); xt+) { 
screenl(YWINDOW+y )*320+XWINDOW+x J= 
tgaLimagenum]. imagely*160+x 1; 


The bitmazeQ Program 


We can construct a simple program along the lines of the GOMAZE program 
from the last chapter to allow a user to take a tour of the bitmapped maze that we 
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draw with the drawmaze() function. Im fact, much of the code in the mainf) 
function of this program will be identical to that in the main() function of the 
GOMAZE program. However, there are some differences. For instance, the 
BITMAZE program will need to allocate an array of variables of type tga_struct 
to hold the Targa images that we must load from the disk: 


‘f/ Array for bitmaps: 
tga_struct tgalVIEW_LIMIT*2+1]; 


And well need to store the names of the nine TGA files in an array, so that we 
can load them using a fort) loop: 
// Array of names for bitmap files: 
char *tga_nameLVIEW_LIMIT*2+1J]= 
{"frontl.tga", 

"fronte.tga", 

"fronts.tga", 

“fronts. tga", 

“fronts.tga", 

"“sidel.tga", 

"sidez.tgqa", 

"side3s.tga", 
“side4.tga” 
I; 
We'll also need a couple of PCX structures. One, which we'll call Sg, will hold the 
background image that you saw earlier in Figure 4-2. This image ts in 
the BITMAP directory in the fle MAZE.PCX and can be viewed with the 
PCASHOW program, Well also need a structure ro hold the image in the hile 
COMPASS.PCA. This image, which can also be viewed with PCASHOW (and 
which appears in Figure 4-15), contains four compass faces, with the compass 
needle pointing in a different cardinal direction in each. In a moment, well move 
these compass faces into an array of compass faces. The PCX structures and array 
of compass faces will be declared like this: 
// Buffers for compass picture and background: 
pex_struct bg,compasses; 


‘/ Array of compass faces: 
unsigned char far *compass_faceLl4]; 


The compass images will be moved from the PCX fle where they are stored into 
the elements of the compass_ face array using a short function called grab, which 
appears in Listing 4-12, This short function, which we'll put in a new module 
devoted to bitmap-related functions called BITMAPCPP, grabs a rectangular 
portion of a 320 by 200 mode 13h bitmap from a buffer and copies it into a 
bufter. The parameters are the upper-left coordinates of the rectangle to be 
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Figure 4-15 The bitmapoed maze depicted by BITMAZE 


grabbed, the width and height of the bitmap, a pointer to the buffer holding the 
320 by 200 image, and a poinrer to the buffer into which the bitmap is to be 
copied. 





Listing 4-12 The grab\) function 


¥otd grablint x1,int y1,int width, int height, 
unsigned char far *screen, 
unsigned char far *buffer?) 


T 
for Cint y=0; y<height; y++) 
for Cint x=0; x<width; x++) 
bufferly*width+xJ=screenl(yi+y)*3204x14+xI; 
} 


(ince we ve FOr the COMPASS face Images in the ArT ay, we Il ave them Onto the 
display using another function from our BETMAPCPP module, called &/e(). The 
word “blit” is short for “bit block transfer,” a commonly used term for the 
process of moving rectangular bitmaps between computer memory and video 
memory, or from one location in video memory (or an offscreen video buffer) to 
another. [he text of the #4¢/) function, which is quite similar to the grab() 
function, appears in Listing 4-13, 
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Listing 4-13 The blit() Function 


void blitCint xl,int yl,int width,int height,unsigned char tar *screen, 
unsigned char far “sprite) 
{ 
for (int y=0; y<height; ++) 
for Cint x=0; xewidth; x++) { 
unsigned char byte=spritely*width+xJ; 
if (byte) screenl(yl+y)*320+x14+xJ=byte; 
} 


The 4/4) function treats values of 0 in a bitmap as transparent — that is, It 
doesnt copy them to video memory. lt does this by checking to see if byte is non- 
zero before it copies the pixel value. This allows us to create rectangular images 
with nondisplaying areas in them, through which the background can show. 

Well also need to create a new maze, since the one we used in the last two 
chapters doesnt fit OL needs ATV RTOre. Most importantly, Wit need a Mate 
expressly designed a that the viewer Cannot see more than five StU LLAPCS in anny 
direction. Here is an array containing such a maze: 


// MAP OF THE MAZE 

iif 

‘/ Each element represents a physical square within the maze. 
// & value of 0 means the square is empty; a nonzero value 

/* means that the square is filled with a solid Block. Map 

ff must be designed so that no square can be viewed over a 

‘/ greater distance than that defined by VIEW_LIMIT. 
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We'll place the viewer initially at a coordinate position of 3,7 within the maze: 


‘/ Viewer's starting position: 
struct xy pos={3,/}; 


We'll also start out with the viewer facing north: 


int dir=0; // Viewer's current heading in maze, 
‘ff where O=north, )=east,2=south,35=west 


As the main() function begins, we Il use the aaaPCA() function to load in the 
file containing the compass face images and the grzh() function to move those 
Images into the compass face array: 


‘/ Load compass picture: 
if (lLoadPCX("compass.pcx",Scompasses)) exit(1); 


‘/ Load compass faces into array: 
for Cint num=0; num<4; numt++) { 
compass faceCnumJ=new unsigned charl42*411]; 
grab(17+num*50,18,42,41,compasses. image,compass faceCnumd); 
} 


We ll then use the delete function to get rid of the memory occupied by the 
COMPASS.PCX image, since its no longer needed: 


‘? Dispose of compass picture: 
delete compasses.image; 


We'll also use the foadPCX{) function to load the background image into 
memory: 


‘/ Load background image: 
1f CloadPCK("maze.pcx",&bqg)) exit); 


And well use the oad [GA() function, along with the hle names that we stored in 
the ¢g@_name array, to load in the ray-traced images of the maze: 
// Load maze bitmaps into TGA array: 
for Cunsigned int i=0; is(VIEW_LIMIT*24+1); j++) 
if (loadTGA(tga_namelil,&tgalil}) exit(1); 


Then we'll engage in exactly the same setup that we used in the GOMAZE 
program in the last chapter, except that we'll copy the background image into the 
offscreen video buffer before moving the image into video memory: 
// Put background image into buffer: 

for (i=0; 1<64000; i++) 

screen_buftferli J=bg. imagelid; 

Well draw an initial image before we begin the main wile’) loop thar drives the 
game: 
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/f Put screen buffer on sereen: 

blitscreen(screen_buffer); 

The main whie() loop is identical to the one in GOMAZE, except that we blit a 
compass face onto the display every time the loop executes: 


ff Put compass next to maze window: 
blit(20,35,42,41,5creen,compass faceldir]); 


And we call our new drawmase(! function with its new parameters: 


‘? Draw the maze in screen buffer: 
drawmaze(0,0,0,159,screen_buffer)}; 


The complete text of the new maia() function appears in Listing 4-14, The 
complete program ts available on disk as BTMAZE.CPP in the BITMAP directory. 





Listing 4-14 The main) Function from BITMAZE.CPP 


void main(void) 

{ 
event_struct events; 
struct xy newpos; 


ff Create pointer to video memory: 
char far “screen=(char far *)MK_FPCOxa000,0); 


// Create offscreen video buffer: 
char far *screen_butffer=new unsigned char Cé4000); 


// Load compass picture: 
if (loadPCX("compass.pcx",&compasses)) exit(1); 


// Load compass faces into array: 
for Cint num=0; num<4; numt++) f 
compass faceCnumJ=new unsigned charl42*41]; 
grab(17+num*50,18,42,41,compasses.image,compass_facelnumd)}; 
} 


‘/ Dispose of compass picture: 
delete compasses. image; 


‘! Load background image: 
if CloadPCX("maze.pex",&bg)) exit(1); 


‘? Load maze bitmaps into TGA array: 
for (unsigned int i1=0; i<(VIEW_LIMIT*2+1); i++) 
if (LoadTGACtga_namelil,£tgalij)}) exit(1); 


ff Initialize event manager: 
init_events(); 
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ff Calibrate the user's joystick: 

if (WHICH_EVENTS & JOYSTICK_EVENTS) f{ 
printt("\nCenter your joystick and press button "); 
printf<{"one. in"); 
setcenter(J; /f Calibrate the center postition 
printft"Move your joystick to the upper lLefthand "); 
printf{"corner and press button one.\n"J; 
setmint); ff Calibrate the minimum position 
printt("Move your joystick to the Lower righthand "); 
printf{"corner and press button one.\n"); 
setmax(); ff Calibrate the maximum position 


ff Save previous video mode: 
int oldmode=*(int *)MK_FPCOx40,0x49) ; 


ff Put display in mode 13h: 
setmodetOx13) > 


if Set palette to PCX palette: 
setpalette(tgaL0].color_map) ; 


ff Clear display: 
els(screen_buffer); 


// Put background image into buffer: 
for (7=0; 1<64000; 14+) 
screen_bufterlild=bg. imagelid; 


ff Set number of ticks per frame: 
ticks per_frame = CLKE_TCK / FRAMES PER_SECOND; 


ff Initialize the frame timer: 
clock_t lastTrame=clock() > 


/f Make sure we get at Least one frame 
ff into the mare: 
events.quit_game=(0; 


‘f/f Put initial image of maze in screen buffer: 
drawmaze(0,0,0,159,screen_buffer); 


if Put screen buffer on screen: 
blitscreen(screen_buffer); 


ff Let's go for a walk in the maze: 
while(!events.quit_game) f 


‘/ Draw the maze in screen buffer: 
drawmaze(0,0,0,159,screen_buffer); 


‘/ Move screen buffer to screen: 
putwindow(XWINDOW, TWINDOW,160,100,screen_buffer); continued on MENT page 
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continued fro presiows page 


// Put compass next to maze windaw: 
blitt20,355,42,41,s5creen,compass faceldirJ); 


// Pause until time for next frame: 
while ((clock()-Lasttrame)<ticks_per_frame) ; 


ff Start timing another frame: 
Lastframe=clock(); 


ff Move viewer according to input events: 
getevent(WHICH_EVENTS, fevents); 


// Do we want to move forward? 
if (events.go forward) f 
newpos .x=pos.x+forwardLdird.x; 
newpos.y=pas.y+ttorwardldird.y; 
if ('mazeCnewpos.x]Jinewpos.yJ) { 
pos. x=newpos.x; 
pos. y=newpos.¥; 
} 
; 


f/f ...0P do we want to move backward? 
else if (events.go_back) f 
newpos.x=pos.x-forwardlLdird.x; 
newpos.y=pos.y-forwardldird.y; 
if ('mazelCnewpos.xJCnewpos.yJ) f 
pos.x=newpos. x; 
DOS. ¥Y=newpos.y¥; 
} 
} 


if Do we want to turn lett? 
if fevents.go_left) f 
=—“dir: 
if (dir<0) dir=3; 
} 


ff ...0P do we Want to turn right? 
else if Cevents.go_right) f 
airt+t; 
if C(dir>3) dir=0; 
} 
} 


f/f Terminate event manager: 
end_events(); 


‘/ Release memory 

for (int 71=0; Ti<(VIEW_LIMIT*24+1); i++) f 
delete tgaliil. image; 
delete tgaliil.color_map; 





CHAPTER FOUR Manipulating Bitmaps 


if (tgalii].1D) delete tgaliil.1D; 
} 
delete bo.image; 
for Cint jj=0; jj*4; delete compass_taceljj++]); 
delete screen_bufter; 


ff Restore old video mode: 
setmodetoldmode) ; 
} 


Touring the Maze 


The bitmapped maze program WOFKS exactly like che wireframe maze program we 
presented in the last chapter. (50 to the BET MAP directory and cy pe: 


bitmaze 


The birmapped maze screen will appear (sec Figure 4-16). Use the keyboard, the 
mouse, or the joystick to move around through the maze. (The keyboard is 
recommended.) When you ger tired of running around through ray-traced 
passageways, hit (Esc) to rerurn to the DOS prompt. 

While youre in the maze, be sure to notice some of the highpoints of the tour. 
My own favorite part of the maze are the reflections on the polished floor, added 
courtesy of the POV ray tracer. Also notice that you can never see more than four 
squares in front of the one youre standing in. If you're curious what would 
happen if you could see further than this, try making random changes to the 
maze array to see what happens. [his wont crash the program — at least, 1 
shouldn't, since we look for this possibility at the beginning of the drtwmazer) 
function — bur it will produce some odd effects. 





Figure 4-16 The bitmapped maze depicted by BITMAZE 
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Should you become bored with the green walls, checkered Hoors, and blue 
skies in this maze, [ve supplied some hles on the disk that you can use to 
produce new maze graphics — #f you have the POY ray tracer. Full instructions 
are included in Appendix A for using POV to generate new mazes. In addition, 
l've provided batch files to automate the process, and a few alternate maze files to 
generate mazes with quite different appearances from the default maze supplied 
on the disk. These are also explained in Appendix A. 


Refining the Maze Engine 


Although we'll ring some interesting variations on it in later chapters, we wont be 
adding any more bells and whistles to this particular maze engine; instead, were 
eoing to move on to more advanced types of maze code, Nonetheless, the code 
presented in this and the preceding rwo chapters could make the core of a pretty 
good commercial game engine, which could be used to produce maze games 
along the lines of Eve of the Beholder or Crusaders of the Dark Savant. 

Still, chis engine sutters trom a few ineficiencies, some of which we remarked 
on earlier, These will need to be fixed if you want to use this code as a model for 
a Made eng! ne ot YOUL OVW. 

Perhaps the most important of these inefhciencies is in the way it uses 
memory. Storing nine complete 160 by 100 TGA images from which to 
construct the views of the maze is not a particularly efhcient way to handle 
bitmaps. A quick elance will tell you that much of what appears in these bitmaps 
is redundant. The sky and floor, for instance, are repeated from image to image, 
when they really only need to be stored once. Of course, this allows us to pull off 
some nifty effects, like the reHlections of the maze walls that appear in the shiny 
tiled Hoor. However, losing this reflection effect would be a small price to pay in 
order to use memory more efficiently, The best way to remove the Hoor and sky 
redundancy is to store an image of the Hoor and sky in a separate TGA (or PCCX) 
hile and Move that 1 Mare into the wiew window before drawing ell’ ot the walls, 
then draw the walls over the top of this image using the br) function or an 
equivalent function that recognizes transparent pixels in a bitmap. 

The wall images themselves are stored inethciently, The SIDE4.TGA fle, for 
instance, barely has any walls in it at all — and some of the other SIDE images 
have large portions without walls in them. A way around this inefheiency would 
be to load the TGA images in briely during program initialization, slice the useful 
portions of these bitmaps out with the gree() function and store them in smaller 
arrays, then throw the rest of the images away. This ts left, inevitably, as an exercise 
for the reader, The multiple FRONT images are also probably not necessary. One 
front-of-block image could be stored at each distance, then moved: horizontally 80 
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thar it could stand in for all of the other front images at that distance. (In chapter 
6, well look at a method of reducing the storage requirements even further by 
taking only a single front image and using that image to generate not only all of 
the other front images bur the side images as well.) 

Yer another way to save memory would be to compress the graphics data, to 
make the memory use even more efficient. You could use an RLE compression 
system similar to that used in PCX files. Decompressing graphics will slow the 
display functions down slightly, but high frame rates aren't as important in 
bitmapped maze programs like this one as they are in the flight simulator-style 
programs well be demonstrating later. Because the player moves through the 
maze by quantum-leaping from square to square, Hashing the frames on the 
screen too quickly would cause the player to zip across the maze in only one or 
rwo seconds, which wouldnt be desirable. 

Compressing the graphics data could in turn help you cure another problem 
with this maze engine — the inability to see more than four squares beyond the 
square in which you are standing. This ts, in many ways, a memory limitation: 
We don't have room to store any more TGA images without overflowing the 
limited space that DOS provides us with in the first 640 kilobytes of the 
computers memory, Each 160 by 100 TGA image takes up 16 kilobytes of 
memory. That may not sound like much, but it adds up. BITMAZE uses about 
144 kilobytes of memory for [GA images, plus an additional 64 kilobytes for the 
background image loaded from the hle MAZE.PCX. More than this we really 
don't want to spare for graphics. Burt if you can find a more efficient way to use 
memory — by throwing out the redundant parts of the TGA images, for 
instance, OFT by compressing the eraphics — You could Store images of the Maze 
walls out to five, six, seven, or more squares in front of the viewer. (An alternate 
way to handle this problem is to design the maze graphics so that they seem to 
fade into darkness with distance. Then it would appear realistic that the viewer 
could only SCC four SPLAT CS. ahead. However, | Was unable To tweak the POV ray 
tracer into providing this particular effect, so you may need to design such 
images by hand, using a paint program.) 

Perhaps even more importantly, you will want to provide a greater variety of 
wall images, especially images of walls with doors in them, or with decorations 
mounted on them. Uhis will provide a more interesting visual environment for 
the game player. These alternate images could be taken into account in the 
maze// array by using numbers other than | to designate squares filled with 
blocks. For instance, the number 2 could indicate a block with a door in it, the 
number 3 could indicate a block with wall sconces on it, and so on. However, 
this will require storing still more bitmaps, which will put a tight squeeze on your 
lower 640 kilobytes of memory even with more efficient methods of storing 


graphics. 
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At this point, you may want to turn to expanded memory, or EMS, to loosen 
the crunch. We wont be discussing expanded memory in any derail in this book, 
but you can find information on it in a number of books on system-level PC 
programs. Basically, EMS provides your program with a standard method of 
accessing the memory in your machine beyond the | megabyte address barrier, 
via a buffer called a page frame located in high memory. You can call DOS to 
switch the contents of your computer's extended memory into this buffer 64 
kilobytes at a time. (Older computers used special memory boards to provide 
expanded memory, but 386 and 486 computers — the machines that we're 
targeting with the programs in this book — use the extended memory beyond | 
megabyte to “emulate” these expanded memory boards, with the help of 
expanded memory managers such as EMM386, which comes with Windows and 
recent versions of DOS.) With the aid of expanded memory, you can greatly 
increase the number of bitmaps that your program is able to store, 

There are alternatives to EMS, most notably XMS and the rwo protected 
mode standards, DPMI and VCPI. You can find information about these in the 
same sources that provide information abour EMS. But XMS is a fairly slow way 
to move data to and from extended memory — essentially, it works like a fast 
RAM disk, copying the data back and forth a byte at a time — and the protected 
mode standards are not yet supported by the Borland C++ compiler. (Ar least, 
they weren't at the time this was written.) In the near furure, one of the protected 
mode standards — probably VCPI, which ts supported by Windows — will be 
the best way to access memory beyond the 640-kilobytes barrier. For the 
moment, though, EMS is probably your best alternative, 


Flying Through the Maze 

The final Haw in this maze engine — and the reason that we wont be expanding 
it any further in this book — ts that, despire the vividly ray-traced bitmaps that 
we used in the graphics, the way in which the viewer must move around in the 
maze is inherently unrealistic. The viewer moves by jumps and spurts, going 
from the Center of One Maze SC Lar Tt the next without passing through the Space 
in between. When rotating in place, the viewer can only take one of the four 
cardinal compass positions. 

What we need to create an even more realistic maze engine is some method of 
incorporating fight simulator-style graphics techniques in our code, to create a 
maze animation with motion as realistic as that in a Hight simulator. This is a big 
order, so big that we'll be devoting the rest of this book to finding a way to fulfil 
it. But fulfill it we will, as we move on into the world of polygon fill graphics, ray 
tracing, and the newest maze game programming technique of all, ray casting, 
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here are many different ways to render a three-dimensional, 
bitmapped world on the video display of a microcomputer, The 
simplest, if not the cheapest, is to hire an artist to paint three- 
dimensional bitmaps using a paint program such as Deluxe Paint 
i or PC Paintbrush, chen incorporate those bitmaps into your 
programs exactly as they were drawn. The results may well be stunning, if the 
artist is talented and experienced in the nuances of computer graphics. But your 
ability to use the bitmaps in a game program will be limited. You can only 
display the bitmapped image in the way that the artist drew it. You wont be able 
to turn it around and see whats on the other side. 

The second easiest method, which we demonstrated in chapter 4, is to have an 





artist (or a rendering program, such as a ray tracer) create parts of an image, then 
slice and dice those pieces onto the screen so as to produce the illusion of a three- 
dimensional universe, Although the images produced by this method are usually 
somewhat less stunning than those an AITISE might create from whole cloth, they 
can be used in a wider variety of ways. With the slice and dice method, you 
actually cam see whats on the other side of the image. Bur there are two 
drawbacks to this method, The first is that storing the bitmaps can require 
inordinate amounts of system memory, which in turn limits the variety of 
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bitmaps that you can incerporate into your game. The second is that the player's 
movements through the game world are constrained by the nature of the 
bitmaps, The player must move by quantum jumps from position to position, for 
the simple reason that there are no bitmaps showing what the world looks like 
from the intermediate positions. 

In this chapter and the next, we'll look at a third method of generating 31) 
graphics in a game program. This method, which we'll refer to loosely as polygon 
graphics, has traditionally been the favored method for drawing landscapes in 
Hight simulators, but until recently it has been little used in maze games, perhaps 
because polygon-based images are not especially realistic when seen from the 
viewpoint of a dungeon-crawling hero, Recent advances in CPU speed, however, 
have made it possible to combine polygon graphics with a technique called 
texture mapping to produce images that are far more realistic than those 
generated with earlier polygon-hll techniques. 

Well discuss the rudiments of polygon drawing on the IBM-PC and 
compatibles in this and the following chapter. Then well use polygon-based 
techniques to create a maze game engine that produces images almost as striking 
as those in chaprer 4, while using up only a fraction as much memory. Finally, 
before we move on to more advanced techniques in chapter 8, well discuss how 
these techniques could be used to produce a fully three-dimensional dungeon, 
through which the player can move smoothly and realistically. 


Filled and Unfilled Polygons 


A polygon is a shape defined by three or more edges, like the triangle in Figure 
5-1 and the square in Figure 5-2, Theres no requirement that these edges be of 
equal length, as YOU can see by looking at the hve-sided polygon in Figure 3-3. 
The point at which two edges come together is called a vertex. Because a polygon 
is always completely enclosed — that is, the edges form a continous border 
around the polygon, with the last edge linked to the first — the number of edges 
in a polygon will be the same as the number of vertices, 

Drawing a polygon on the video display of a computer isnt particularly 
difficult. The only information we would need to store about the polygon or 
polygons to be drawn is the location on the computer display of the vertices. We 
could then link these vertices with lines by calling the line-drawing function from 
chapter 2, Listing 5-1 contains a short program that draws a four-sided polygon 
on the mode 13h display. The result of running the program is shown in Figure 5-4. 
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Figure 5-1 A triangle is an example of a Figure 5-2 And so is asquare 
simple Polygan 





Figure 5-3 A polygon with five irrequiar 
Sicles. 





Listing 5-1 POLYGON.CPP 


ff POLYGON.CPP Version 1.0 

‘/ Draws an unfilled polygon on the mode 13h display 
ff 

ff Written by Christopher Lampton 

// for Gardens of Imagination (Waite Group Press) 


Ainclude <stdio.h> 
Finclude <conio.h> 


ovatrirued mr Hea Pare 


165" 





GARDENS OF IMAGINATION 


Canned from Drew pucker 
Finclude <=dos.h> 
Ainclude "“screen.h" 
finclude “bresnham.h" 


vold main(int arge,char *argvlJ) 
{ 
/*# Create pointer to video memory: 
char far *scereen=(char far *)MK_FP(Oxa000,0): 


‘f Save previous video mode: 
int oldmode=*(Cint *)MK FP¢(Ox40,0%49) > 


ff Put display im mode 13h: 
setmode(Qx13); 


if Clear display: 
cls(sereen); 


f/f Draw polygon: 

Linedraw(1/,24, 10/,65,15,screen); 
Linedraw(107,68,1790,79,15,screen); 
Linedraw(190,79,1750,1780,15,screen); 
Linedraw (150,180,17,24,15,screen) 


while (!kbhit()); 


ff Restore old video mode: 
setmodeloldmode) ; 


The polygon drawn by the program in Listing 5-1 ts an unhiled polygon — 
thar ts, it has a visible border but nothing inside that border. With only a few 
exceptions, the polygons used in games depicting three-dimensional 





Figure 5-4 The screen output fram the program POLYGON. CPP 
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environments are filled polygons. In a filled polygon, there is something inside 
the border. Just what that something is may vary from game to game. 

In the simplest type of filled polygon graphics, the polygon is filled with pixels 
of a single color. This gives the polygon the look of solidiry, as though it were a 
solid object rather than a collection of pixels on a video display. Several such 
polygons can be put together to form the three-dimensional image of an entire 
object, such as a building or an airplane. And, in fact, such solid-color hilled 
polygons were until recently the basis of almost all the Hight simulators on the 
market. This technique is so popular that images produced in this manner are 
usually referred to simply as polygon-fill graphics. 

There are other ways co fill a polygon, which we'll talk about in a moment, 
For the moment, we'll take a closer look at polygon-fll graphics to see if they 
might be useful to us in creating a realistic maze game. 


Filling a Polygon 


Drawing a filled polygon on the video display of a microcomputer is a bit more 
difficult than drawing an unhiled polygon. In this chapter we'll simplify this task 
by restricting the shape of our polygons to those that will be useful in a maze 
game. Whar sort of shapes do we want to draw? Pretty much the same shapes as 
we were drawing in chapter 4: four-sided wall segments. This, in fact, is the only 
type of polygon that most maze game engines can draw. (The Ultima 
Underworld games appear to be an exception to this rule.) More complex objects 
are depicted with predrawn bitmaps, which are superimposed on top of these 
polygons, (We'll talk more about superimposing predrawn bitmaps in a later 
chapter.) 

So all We really need co draw Ate four-sided polygons. However, this doesnt 
mean that well only be drawing rectangles. We'll also need to rotate these four- 
sided polygons, so that we can depict them as they would appear from various 
angles. This means we cant restrict ourselves to drawing only those polygons in 
which the edges meet at right angles. Which 1 Is Coo bad, since such polygons Are 
quite easy to draw. 

However, we can still simplify our task by restricting the rotations of these 
polygons to these rotations that take place around the polygons local y axis. This 
means that the polygons we draw can rotate like tops (see Figure $-5), bur cannot 
roll head over heels (Figure 5-6), or spin like a propeller (Figure 5-7). This 
shouldn't noticeably inconvenience the player, since most movement in a maze 
game is one-dimensional. There's no reason, for instance, that the player will 
need to tilt his or her virtual head to one side, causing the polygons to appear to 
rotate on their z axes. Nor will the player need to do forward rolls down the maze 
corridor, causing the polygons to appear to rotate on their x axes. We do, 
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Figure 5-5 A polygon rotating tke a top Figure 5-6 A polygon rolling head over 
around its bocal y axis heels around its jocal * axis 





Figure 5-7 A polygon spinning like a 
propeller around its local z axis 


however, want to give our players the ability to move up and down within the 
maze, simulating crouching or standing on top of raised plarforms. 

What well be drawing, then, are polygons representing wall segments that 
appear to rotate on their local y axes but that can also be depicted in such a way 
that the player seems to be looking at them from a low vantage point or a high 
yantage point, Thus well need a polygon-drawing function that will draw filled 
four-sided polygons in which the right and left edges are perfectly vertical but in 
which the other two edges can take any orientation whatsoever (except for 
, since that would make them parallel to the other two edges). 
Figures 5-Ha through d show examples of the sort of polygons that we ll be 
drawing. 
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The polytype Structure 


Before we can write a function that draws a polygon, we need to define a variable 
structure that will hold a description of the polygon to be drawn. This structure 
Can then be passed to the polygon-drawing function cls ill Paramecner. All that we Il 
need to place in this structure are the x,y coordinates at which the vertices of the 
polygons will be drawn on the video display. Since were restricting our polygon 
drawing to four-sided polygons, this can be handled with a pair of four element 
arrays, one for the x coordinates and one for the y coordinates. Here's the 
dehnition for the polyrype structure, which well place in the hle POLYDRAW.H: 


struct polytype f 
int x€4J; 


int yC4I: 
IF 


Polygon Clipping 


There is one other thing that we need to take into account before we start writing 
our polygon-drawing function. In a maze game, all of the action takes place in a 
rectangular window on the video display, [his window is sometimes called the 
viewport, In drawing a three-dimensional image of the maze, we must be sure 





Figure 5-8a-d Four types of polygons that our polygon 
drawing function will be called on to draw 
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that we don't accidentally draw outside of the confines of this viewport. In earlier 
chapters, this has been a simple enough task. In chapter 4, for instance, we 
handled this by passing a pair of values to the maze-drawing function that 
defined the limits of the viewport, and we carefully kept all of our sliced and 
diced bitmaps inside those limits. 

The task of keeping polygons inside the viewport is a bit more complex. In 
Figure 5-9a, for instance, a four-sided polygon needs to be clipped against rhe 
side of a viewport, Once clipped (as in Figure 5-9b), this four-sided polygon 
becomes a hive-sided polygon, Thus, even though we have restricted the polygons 
that well be drawing to four-sided polygons, in practice these polygons might 
turn into five-sided or even six-sided polygons after being clipped at the edge of 
the viewport. 

There are two general ways of handling polygon clipping. We can write a 
function that will accept a polygon definition and which returns to us a version 
of that polygon definition that has been clipped against the four edges of the 
viewport. There are standard algorithms for doing this. However, they are useless 
to us if we conhne ourselves to drawing four-sided polygons, because clipping 
may add extra edges to the polygon. The pol/prype structure wouldnt even be 
capable of holding a description of a five-sided polygon. 

We dont want to abandon the simplicity of the polptype structure, so well use 
the second method of clipping polygons, This method places the clipping in the 
polygon-drawing function itself. The function will watch for polygons that need 
to be clipped against the viewport and will do the clipping on the fly. Although 
this complicates the polygon-drawing function, it simplihes the rest of the 





Figure 5-94 A four-sided polygon that Figuré 5-96 The four-sided polygon 
needs to be clipped against the side of a becomes a five-sided polygon after 
Viewport cloping 
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program. All we have to do when we draw a filled polygon is to call che polygon- 

drawing function, then pass it a description of the polygon in a polytppe structure 
5 P | a, 

along with the dimensions and location of the viewport we wish the polygon to 

be clipped against. 


A Polygon-Drawing Function 
We'll call the polygon-drawing function polydraw(). Here's the prototype for the 
function: 


void polydraw(polytype *“poly,int leftx,int Lefty,int rightx, 
int righty,int color,char *screen); 


We'll place this protorype in the fle POLYDRAW.H, along with the pofsrruct 
definition. We'll place the polydraw function itself in the fle POLYDRAW.CPP. 

A description of the polygon to be drawn is passed to polyanawi) in the 
polytype structure poly. (Actually, a pointer to this structure is passed to 
polydraw(); we dont want to waste the CPU's time by passing the entire 
structure.) To simplify our polygon-drawing algorithm, we will observe the 
convention that the coordinates of the upper-left corner of the polygon will be in 
paly->x/0/ and poly->)/0/, with the remaining elements of the x and » arrays 
holding the coordinates of the remaining corners, moving clockwise around 
the polygon. Thus, pofy->x/1/ and pely->y/1/ will contain the coordinates 
of the upper-right corner, poly->x/2/ and pely->y/2/ will contain the coordinates of 
the lower-right corner, and poly->x/3/ and poly->y/3/ will contain the coordinates 
of the lower-left corner. (See Figure 5-1.) 

(Strictly speaking, we dont need to include the pofy->x/2/ and poly->x/3/ helds 
in the polygon structure, since were going to observe the convention that all 
polygons have perfectly vertical right and left edges and therefore the same x 
coordinates at the top and bottom vertices of that edge.) 

The lefire and lefty parameters represene rhe x and ¥ coordinates ot the Upper: 
left corner of the viewport that the polygon is to be clipped against. The rightx 
and righty parameters represent the coordinates of the lower-right corner of the 
viewport. The color parameter is the palette number of the color in which the 
polygon is to be drawn and the “screen parameter is a pointer to the video display 
or to the buffer in which the drawing is to take place. 


The Polygon-Drawing Algorithm 

How will we go about drawing the polygon? The algorithm that we're going to 
use will break the polygon into a series of lines, each of which will be drawn on 
the video display with a for() loop. Figure 5-11 shows how this will work. Figure 
5-lla shows an unhilled polygon drawn as a series of connected edges. Figure 
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Figure 5-10 The coordinates of the 
vertices of the polygon will be specified 
in clockwise order starting at the upper- 
left commer 


5-1 1b shows a filled version of the same polygon drawn as a series of vertical 
lines. What makes this drawing algorithm possible is the fact that we have 
limited ourselves to polygons with vertical left and right edges. The left and right 
edges will be treated as wo of the lines in the polygon’s fill. 

Figuring out where to draw these two lines will be simplicicy itself: The line 
for the left edge will be drawn vertically from coordinates poly->x/0/, poly->y/0/ to 
paly->x/3/,poly->y/3/ and the right edge will be drawn vertically from coordinates 





Figure 5-11a An unfilled polygon drawn Figure 5-11b The same polygon drawn 
as 2 series of connected edges a5 40 5eries of vertical lines 
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poly->x/[1},poly->y[1] to poly->x/2/,poly->x/2]. The real trick in drawing the 
polygon will be figuring out where the intervening lines will be drawn. It helps to 
remember that the Cop and bartom coordinates of these lines atic all pots On the 
[Op and bottom edges of the polygon. Thus, we can calculate these coordinates 
the same way we calculate the points on a line, using Bresenhams algorithm. 

If you were paying attention back in chapter 2, youll recall that Bresenhams 
algorithm uses a form of incremental division to calculate the changes in 
coordinates along a line. A value known as an error term is maintained and the 
difference between either the y or x coordinates of the endpoints (whichever was 
smaller) is added to this value and the value is compared with the length of the 
line on each iteration of the line-drawing loop. When the error term becomes 
ereater than the length of the line in the other dimension, the pixel position ts 
advanced in the direction represented by the error term. We can use that same 
trick to calculate the endpoints of the vertical lines making up the polygon, 
cxCept that we || need tO maintain a patr of crror terms — one for the top 
coordinates of the line and one for the bottom coordinates. 


Clipping Against the Left Edge of the Viewport 


Before we can perform any polygon drawing, we must perform some polygon 
clipping. However, in the name of efficiency, we are going to employ different 
methods for clipping against each edge. We could simplify our task greatly by 
having the polygon-drawing function step through all of the vertical lines that 
make up the polygon, checking before drawing to see if the line falls within the 
viewport. If the line is not in the viewport, it would simply not be drawn. 
Similarly, when drawing the individual pixels that make up the vertical line, the 
function could check to see if each pixel is outside the viewport and not draw tt if 
itis. This method, however, would waste a lot of the CPU's valuable time, since 
it would require the function to step through a large number of lines and pixels 
that dont need to be drawn. 

Fortunately, there's an alternate method that we can use to clip the polygon — 
or, rather, several alternate methods. During the initialization portion of the 
polygon-drawing function, we can check to see if any portion of the polygon 
extends beyond the left edge of the viewport. If it does, we can recalculate the 
coordinates of the upper-left and lower-left corners of the polygon to reflect the 
point at which they cross the edge. This method has a disadvantage too: It will 
require Hoating point math, which is notoriously slow. If the user has a math 
coprocessor in his or her computer, this method will still probably be faster than 
the first method; but if no math coprocessor is present, this method could well be 
slower. Since the majority of machines now have math coprocessors installed — 
the coprocessor comes standard with every 486DX chip, though not with the 
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4865 — well go with this second method. (In a later chapter, we'll discuss fixed 
point arithmetic, which can provide us with a high speed replacement for the 
slow floating point operations that well be using in this chapter. Readers 
interested in speeding up this program may want to rewrite it using hxed point 
math, which should run faster both on machines with coprocessors and without.) 
We can check for a polygon that crosses the left edge of the video display by 
comparing the value of pely->x/0/, the x coordinate of the upper-left corner of 
the poly eT being pointed Tt} by the parameter pal, with the value of lefin, the xk 
coordinate of the upper-left corner (and therefore the common x coordinate of all 
points on the left edge) of the viewport, to see which is smaller: 
if (poly->xClOJ<leftx) f 


If poly->x/O/ is smaller than /eftx, we know that the polygon extends past the 
left edge of the viewport. So well need to recalculate both poly->x/0/,poly->y/0/ 
and poly->x/3/,poh->y/3/, (Actually, we don't need to recalculate poly->x/3/, since 
it should always be identical to poly->x/0/.) Recalculating the x coordinates where 
rhe Upper and lower edges of the polygon CTOSS the lett edge of the screen Is 
simple enough. We can simply reset these coordinates to the x coordinate of the 
left edge, which is stored in /eftx. Finding the y coordinates at which the edges 
cross the left edge is a bit tougher. Well need to use the so-called point-slope 
equation to find these coordinates, which will in turn require some Hoating point 
(or hxed point) math. 


Calculating the Slope 


First we must calculate the slopes of the edges. You'll recall from chapter 2 thar 
the slope of the line is the ratio of the change in y coordinates along the length of 
the line to the change in x coordinates. Thus, to obtain the slope, we must divide 
the change in the y coordinate by the change in the x coordinate. In fact, welll 
need to do this twice, once for the upper edge of the polygon and once for the 
lower edge of the polygon, since each of these can have a different slope. We'll 
store the slope of the top edge in the variable #s/ope and the slope of the bortom 
edge in the variable dslope, like this: 


tslope=(float) (pol y=->y01J-poly->yl0])/ (poly-ex01]-poly->xf07) ; 
bslope=(float)(poly->yl3J-poly-=yC2))/(poly=>xl0J=-poly=>x01)); 


As in chapter 2, we determine the change in x and y coordinates by subracting 
the initial x and y coordinates of the line from the ending x and y coordinates, 
You'll notice that we dont reference pofj->x/2/ and paly->x/3/ when calculating 
the slope of the bottom edge, using instead the starting and ending points of the 
upper edge. In fact, we'll never reference the x coordinates of the lower edge 
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anywhere in the polydraw() function, using instead the identical x coordinates of 
the top edge. This allows us to safely skip some operations that reference the x 
coordinates of the bottom edge, making this function slightly more efhcient. 
You'll also notice that we force the value of the division to Hoating point with the 
(float) cast. If we failed to do this, the result of the division would be an integer, 
even though ¢lope and bslepe (declared earlier in the function) are Hoating point 
variables. 


The Point-Slope Equation 

Now that we have the slope, we can calculate the y coordinate of the edges using 
only rhe slope, the x coordinate of the edge co be clipped against, anal the 
coordinates of one point on each line (hence the name “point-slope equation’), 
The general formula for this 1s: 


new_y = y + slope * (xmin - x) 


where x and y are the coordinates of any point on the line, xmin is the x 
coordinate of the left edge, and mew_y is the y coordinate of the point at which 
the line crosses the left edge. Using this formula, we can use éslope and dbslope to 
find the new coordinates ot the UppPcr- and lower-left COPrMers of the polygon: 


poly->ylOJ=poly—>ylOJ+tslope*(leftx-poly—>xl0]); 
poly->yL3J=poly—>y[3J+bslope*( leftx—-pol y->xL0J) ; 
poly=->x(OJ=Leftx; 


Youll notice that this code ignores the x coordinate of the lower-left corner, using 
instead the identical x coordinate of the upper-left corner. And the new value of 
that coordinate isnt calculated here, since we wont be using it later. This ends 
the initial polygon clipping, though we'll be doing more in a moment, There's no 
need to check right away to see if the polygon extends past the other three edges 
of the viewport, since well be using different methods for clipping each of these. 
More about this in a moment. 


The Drawing Begins 

Since the x and y coordinates at which we are drawing will change as we traverse 
the polygon from left to right, well store the initial drawing coordinates in the 
integer variables x and y. Initially, these values will be equal to the coordinates of 
the upper-left Comer, 


Int x=poly=>xLO1; 
int y=poly->yCOJ; 
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Now we need to calculate the changes in the y coordinates along the top and 
bottom edges, for the variation on Bresenhams algorithm that we'll be using to 
draw those edges. We'll store the difference in y coordinates for the top line in 
the integer variable topd:/f, and the difference in y coordinates for the bottom line 
in the integer variable botediff: 
int topdiff=poly->y01]-poly->yl01; 
int botdiff=poly—>yl2]-poly->y(31; 

We also need to calculate the height of the first vertical line to be drawn in the 
polygon, Since this line is at the far left edge of the polygon, its height will be the 
SalTIC As the height of the lett edge: 
int height=pol y->y¥C3J—-poly->y COI; 


We also need to know the width of the polygon — that ts, the number of 
vertical lines that we will be drawing, This value can be obtained by subtracting 
the x coordinate of the polygon’s left edge from the x coordinate of the polygons 
right edge and adding | to it: 


int width=poly=>xC1J=<poly=>xC01+1; 


Clipping Against the Right Edge 

The value that we use here tor the x coordinate of the left edge has already been 
clipped against the left edge of the viewport. However, the value that we are using 
for the x coordinate of the right edge has not yet been clipped. So we must check 
ro see if the line needs clipping: 

if (poly->xC1J>rightx) 


If it does need clipping, we only need to revise the value of width to reHect the 
width of that portion of the polygon that will actually be drawn — that is, the 
portion inside the viewport. Its not necessary to recalculate the x and y 
coordinates at which the two edges cross the right edge of the viewport. Instead, 
we ll write the drawing code so that it stops drawing when it reaches thar edge. 
Because we'll be using the variable wide as part of the Bresenham code, we'll put 
the revised value in a new variable, which we'll call ewideh. This integer variable 
will be assigned a value equal to the distance berween the right edge of the 
polygon and the right edge of the viewport if the two overlap. Otherwise, it will 
be set to the current value of wrarh: 


vwldth=width-(poly->xl1J—-rightx): 
else vwidth=width; 
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The Error Terms 


Bresenhams algorithm, as was noted in chapter 2, uses a value known as an error 
term to determine when tt ts time to shift the coordinates of the line in x or y 
dimension. We need to calculate the coordinates of the top and bottom edges, so 
we ll use a pair of integer variables to hold these terms. [he one for the top edge 
will be called rperror, and the one for the bottom edge will be called borerrar: 


int toperror=Q; 
int boterror=0; 


The Main Loop 

Now we can begin drawing the vertical lines that will make up the polygon. How 
many vertical lines will we be drawing? One for every pixel in the visible width of 
the polygon, a value that weve already calculated and stored in the variable 
width, We'll use a for() loop to step through the polygon’s width: 


for (int w=0; wewwidth; wrt) { 


The next step is to draw a vertical line from the top edge of the polygon (the 
coordinates of which are stored in x and y) to the bottom edge (the distance to 
which ts stored in the variable /erght). First, however, we must clip the vertical 
line against the top and bottom of the viewport. To clip the top of the line, we 
can compare the value of y with the y coordinate of the top edge of the viewport, 
which is stored in fefty: 
if (y<lefty) f 


If the line extends above the top edge, we'll simply start drawing at the top 
edge. Thus we'll assign the y coordinate of the top viewport edge to the integer 
variable Ly, which will represent the actual point at which drawing should begin: 
vVy=lLeTty; 


Well also need to adjust the height of the line to clip out the portion that 
extends above the top edge of the viewport. We'll store the new height in the 
integer variable whemghr: 

vheight=height-(Lefty-y); 

} 


lf the line doesnt need to be clipped, we'll simply pass the current values of y 
and eight to vy and vbeight 


else f 


Wy=¥ 
wheight=height; 


=] 
us 
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The bottom end of the vertical line also needs to be clipped against the 
bottom edge of the viewport, Should it need clipping, all we have to do is adjust 
the value of the weight variable to reflect the clipped height of the line: 
if (Cwytwheight)>righty) 

wheight=righty-wy; 

Finally, before the line can be drawn, WIC need to calculate the video Miecmory 

address corresponding to the screen coordinates x, vy: 


unsigned int ptr=wy*320+x; 


Drawing the Line 
The actual drawing of the line can be handled by another for() loop: 
fortint h=0; h<wheight; he+) 4 


The variable ptr has been set to the offset in video memory (or within an 
offscreen buffer) at which the next pixel is to be drawn. To draw the pixel, we 
need only store the value of the coler parameter at that location: 


screenlLptri=color; 


We must then advance per to the address of the next pixel to be drawn. Since we 
are drawing a perfectly vertical line, we need simply to add 320 — the width of 
the mode 13h display — to per: 
otr+=320; 
} 

And thar’ all there is to the loop that draws the vertical lines that make up the 
polygon. This innermost loop has deliberately been kept tight, because its where 
most of the CPU cycles are going to go during the drawing of the polygon. 


The Final Details 


Several things must be done before we can move on to drawing the mexr vertical 
line, however, First, we must advance the variable x, which ts used in the 
calculation of video memory offsets, to point to the x coordinate of the next 
vertical line: 


x++; 


Then we must decide whether to move the » offset of the top of the line up or 
down. As in our earlier Bresenham-based line-drawing function, this is done with 
the aid of an error term: 


toperror+=abs(topdiff); 
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You'll recall that the variable topaiff represents the amount of change in the y 
dimension from the first end of the top edge to the second. This value can be 
positive OF negative, depending On whether the line slopes up Or down from left 
to right. When adding this value to the error term, though, we ignore the sign 
and add the absolute value of topdiff to toperrer. If the resulting sum is greater 
than the width of the polygon, we need to adjust the y coordinate of the edge: 
while (toperror>=width) { 


Youll notice that we use a whle() statement rather than an iff) statement here. 
This covers the possibility that the change in y coordinates along the top edge of 
the line may be larger than the change in x coordinates, in which case well need 
to advance the y coordinate by several pixels rather than just one. First, though, 
we subtract the value of wath to reset the error term: 


toperror-=width; 


Then we advance the y coordinate of the top edge of the polygon. Which 
direction do we advance it in? That depends on whether topaiiff is negative or 
positive. If positive, the line must slant downward, so we must increase the y 
coordinate by | 
if (topdiff=0) f 

yt; 

sheight; 
; 
We also subtract 1 from the height of the line so that this instruction doesnt 
Move the ¥ coordinate of the bottom edge down als well, 


lf topalrff is negative, we do the opposite: 


else ¢{ 
met 
height++; 
} 


} 


lf topai/f is equal to 0, then the top edge is perfectly horizontal and we do 
nothing at all, since the value of the y coordinate never changes along a 
horizontal line. Notice that if tepdiff is larger than wide — that is, if the change 
in y is greater than the change in x — this whule() loop will repeat more than 
once, advancing the y coordinate by more than one position. 

We must repeat this sequence for the bottom edge: 
boterrort=abs(botdiff); 
while (boterror>=width) { 


boterror-—=width; 
if Cbotdiff>0) height++; 
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else =-—height; 


When dealing with the bottom edge, we dont need to advance the value of » but 
we do need to change the height of the line, either upward or downward as 
appropriate. Now we are ready to draw the next line, which completes the 
polygon-drawing loop. The full text of the podyaraw function is in Listing 5-2, 


The polydraw() Function 





Listing 5-2 Tne polydraw() function 


Ainclude <stdio.h> 
Finclude <math.h> 
Hinclude “polydraw.h" 


/f Function to draw a polygon defined by POLYTYPE parameter 
ff POLY in color COLOR clipped against a viewport with upper 
// Llefthand coordinates of LEFTX,LEFTY and Lower righthand 
// coordinates of RIGHTX,RIGHTY. 


void polydraw(polytype “poly,int Leftx,int Leftty,int rightx, 
int righty,int color,char *screen) 
{ 
float tslope,bslope; 
int wwidth,wy,wheight; 


ff If polygon crosses Left side of viewport, clip it: 
if (poly=->xCOJ<leftx) f 


ff Calculate slopes for top and bottom edges: 
tslope=(float) (poly->y01l-poly—>yCOlJ)/(poly->x01]-poly->xf0l); 
bslLope=(float)(poly—>yL3J-poly—>¥021])/ (pol y->xCO]-poly->x1]): 


// Find new endpoints for clipped lines: 
poly->y[OJ=poly—->yClOl+tslLope*( Leftx—poly—->xf0]) ; 
poly—>yC3J=poly—>yC3J+bslope*(leftx-pol y=->xC0J); 
poly=<>xCOJ=Letftx; 


// Initialize x,y coordinates for polygon drawing: 
int x=poly->xlO0J; 
int y=poly->yCQJ; 
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‘/ Calculate the change in y coordinates for top 
‘/ and bottom edges: 

int topdiff=poly—->y01J-poly->yC01; 

int botdiff=pol y->yC2J]-pol y->y[3I; 


ff Initialize height and width of clipped polygon: 
int height=poly=->yC3J-poly->y(CO0]; 
int width=pol y->xC1J-pol y->xC0I+1; 


// Clip polygon width against right side of viewport: 
if (poly->xC1)]>rightx) 
wwidth=width-—(poly-=xl1J—-rightx); 
else wwidth=width; 


/f Initialize top and bottom error terms: 
int toperror=0; 
int beterrar=0; 


ff Loop across width of polygon: 
for Cint w=0; wewwidth; wet) f 


// If top of current vertical Line is outside of 
// wiewport, clip it: 
if (y<lefty) 4 
wy=Lefty; 
wheight=height-(Lefty-y); 
} 
else ¢ 
WY=¥; 
wheight=height; 
} 
if (Cwytwheight)>righty) 
wheight=righty—-wy¥; 


// Point to video memory offset for top of Line: 
unsigned int ptr=wy*320+x; 


// Loop through the pixels in the current vertical 
/f Line, advancing PTR to the next row of pixels after 
ff each pixel is drawn. 
forCint h=O; h«wheight; h++) { 
screenLptrJ=color; 
ptr+=320; 
} 
// Advance x coordinate to next vertical Line: 


Xt; 


// Is it time to move the top edge up or down? 
toperror+=abs(topdiff); 
while (Ctoperror2s=width) f 


confinied om méxt pny 
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ff If so move it up... 
toperror==width; 
if (topdiff>0) { 
yt; 
=—<height; 
} 


ff oar down. 
else f 
te 
height++; 


} 


ff Is at time to move the bottom edge up or down? 
boterrort+=abs(botdiff); 
while (boterrorz=width) 


‘f/f If so, move it: 
boterror-=width; 

if (botdiff>0) height++; 
else —-height; 

i 


The POLYDEMO Program 


For a look at the polpedrew() function in action, well write a short demonstration 
program that will draw a polygon on the display. We'll use the same setup that 
weve used in earlier chapters for turning on mode 13h, saving and restoring the 
old video mode, establishing an offscreen video butter, and so forth. Once the 


Init 


of type pelytype to describe a polygon with an upper edge extending 
from coordinates 50,90 to coordinates 250,10 and a lower edge extending from 


alization is complete, we'll plug the appropriate values into a variable 


coordinates 50,100 to coordinates 250,120: 


poly 
poly 


poly. 
poly. 
poly. 
poly. 
poly. 
poly. 


T 


poly 


.x{0]=50; 
.¥COI=90; 
xL11=250; 
yC1J=10; 
xC2J=250; 
y021=120: 
xC3J=50; 
yC3I]=110; 


hen we |! pass chis structure to the polygon-drawing function: 


draw(Epoly,0,0,319,199,1,screen); 
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Figure 5-12 The video output fram the program 
POLYDEMO.CPP 


And that's all there is to drawing a filled polygon. The full text of the program 
POLYDEMO.CPP is shown in Listing 5-3 and the video output is in Figure 5-12. 





Listing 5-3 The POLYDEMO.CPP program 


Ainclude <stdio.h> 
Finclude <dos.h> 
finclude <conio,h> 
Rinclude <stdlib.h> 
Ainclude "“sereen.h" 
Hinclude "polydraw.h" 
AFinclude “bresnham.h" 


void maint) 

{ 
‘/ Declare polygon structure: 
polytype poly; 


‘f Create pointer to video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


// Save previous video mode: 
int oldmode=*(Cint *IMK_FPCOx40,0x49) > 


// Put display in mode 13h: 
setmode(Ox13) > 


/? Clear display: 


els( screen); 


Pree oe ee ee 
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// Put polygon data in POLYTYPE structure: 
poly.xCOJ=50; 
poly. ylOJ=90; 
poly. xl1J=250; 
poly. ¥C1J=10; 
poly.xCeJ=250; 
poly. yL2J=120; 
poly. *xCSJ=50; 
poly. yl3J=110; 


// Draw the polygon: 
polydrawt&ipoly,0,0,319,199,1,screen); 


// Hold polygon on screen until keystroke 
while ('kbhit()}; 


/f Restore old video mode: 
setmode(oldmode) ; 


The POLYCLIP Program 

Ah, but what about the code we placed in the function to clip the polygon 
against a window? How do we know that it works correctly? To find out, we'll 
create a slight variation on POLYDEMO.CPP that will draw a box on the screen 
representing a viewport, then clip the polygon to that viewport. To draw the box, 
we'll resurrect the drawbex() function that we used in chapters 2 and 3. The 
complete listing of POLYCLIP-CPP appears in Listing 5-4 and a picture of its 


video output in Figure 5-13. 





| Listing 5-4 The POLYCLIP.CPP program 


Hinclude <stdio.h> 
finclude <dos.h> 
finclude «conic. h> 
#include <stdlib.h> 
#include "screen.h" 
Hinclude "“polydraw.h” 
Finclude “bresnham.h" 


void drawbox(int Leftx,int Lefty,int rightx,int righty, 
char *“screen); 


void main() 
{ 
// Declare polygon structure: 


Fs || 
=r | 
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polytype poly; 


ff Create pointer to video memory: 
char far *screen=(char far *)MK_FPCOxaQ000,0); 


f/f Save previous video mode: 
int oldmode=*(int *)RAK_FP(Ox40,0x49)> 


‘/ Put display in mode 13h: 
setmode(Qx13); 


ff Clear display: 
cls(screen); 


‘ff Draw box on display: 
drawbox(/0,50,200,130,screen) ; 


poly.xf0J=50; 

poly. yCOJ=90; 

poly. xLiJ=250; 

poly. ¥LIJ=H10; 

poly. xC2J=250; 

poly. ¥C2J=120; 

poly. xC3J=50; 

poly. yl3J=110; 
polydrawlEpoly,71,51,199,129,1,5creen); 


‘ff Hold polygon on screen until Keystroke 
while ('kbhitt)}); 


‘/ Restore old video mode: 
setmode(ol dmode) ; 


} 


void drawboxCint Leftx,int Lefty,int rightx,int righty, 
char *screen) 
[ 
Linedraw(leftx,lefty,rightx, lLefty,15,s5creen); 
Linedraw(rightx, lefty,rightx,righty,15,screen); 
Linedraw(rightx,righty,leftx,righty,15,screen); 
Linedraw(lLeftx,righty,leftx,lefty,15,screen); 


A Polygon Maze 


It's not hard to plug this polygon-drawing function into the maze-drawing 
program that we created in chapter 4. Most of the necessary changes will be in 
the drawmaze() function. We'll also need to recast the array meatrix/], which 
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represents the screen y coordinates at which the horizontal and vertical walls of 
the maze cross one another on the display to take into account points that are 
just off the visible edge of the viewport: 


int matrizCVIEW _LIMIT+2I0VIEWLIMIT*2+21= 
11a/,187,187,187,18", O, O, OG, O, OF, 


(187,187,187,238,143, 47,-469, 0, 0, 0}, 
{187,187,187,179,123, 66, 10, O, O, O}, 
(187, 187,187,158,117, 73, 31, 0, O, OF, 
(167,167,177 ,144,111,. 78, 45, T2, O,-. OF, 
{187,185,159,133,107, 82, 56, 30, 4, O} 


Ie 


Well also need to create two new arrays, which represent the x coordinates of the 
tops and bottoms of the polygons viewed at various distances: 


int topCVIEW_LIMIT+2]={-11,20,36,42,46,49}; 
int bottom( VIEW_LIMIT+2]=(131,99,83,77,73,70}; 


Because some of the polygon edges will actually extend beyond the limits of the 
viewport, we have included values in all of these arrays that exceed the limits of 
our viewport. All coordinates are relative to the upper-left corner of the viewport, 
which is 188 pixels wide, so all negative numbers and numbers larger than 187 
fall outside of the viewport. 


A New Maze-Drawing Function 


The new maze-drawing function will be much like the old one. We'll use the 
same recursive algorithm for determining what walls need to be drawn as we used 
in chaprer 4. (You might want to reread that chapter if youre having trouble 
remembering how the algorithm works.) Almost all of the changes concern the 
function calls that perform the actual drawing. In the bitmapped version that we 
developed in chapter 4. the anewslice() function was called to copy a slice from 
the appropriate bitmap onto the display. These will be replaced by calls to the 
polydraw() function. 

Before we can call polydraw), we must put a description of the polygon to be 
drawn tn a variable of type polytype. The necessary values can be taken from the 
matrix, top, and bettom arrays. Here is how we draw the view through the 
lefthand portion of the current maze square, as required by the recursive 
algorithm that were using: 
poly.xCOl=matrixCyshifti[xshift+VIEW LIMIT+11+XWINDOW; 
poly. ¥LOJ=toplyshiftJ+YWINDow; 


poly.xC1JsmatrixCyshift+1IOxshift+VIEW_LIMIT+1]+XWINDOW; 
poly. yO 1J=toplyshi f t+] J+¥WINbow; 


C 
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poly. yC2J=bottomlyshitft+1 J+yWINbow; 
poly. yC3J=bottomlyshiftJ+YWINbDow; 


Then we call polvaraw() to draw the polygon: 


polydraw(époly,wleft+XWINDOW, TWINDOW,vright+XWInDow, 
YWINDOW+WHEIGHT,2,screen); 


As in the previous version, we pass the x coordinates of the right and left edges of 
the current viewing window within the viewport, contained in the vleffand vright 
coordinates. (See chapter 4 for a more detatled explanation of what these values 
represent.) Now, however, we must also pass the y coordinates of the top and 
bottom of the viewport. Lo all of these values, we must add the offsets of the 
view window (which are contained in the XWINDOW and YWINDOW 
constants) to translate our view window relative coordinates into absolute 
coordinates on the video display. 

We repeat chis process to draw the view over the middle portion of the current 
square: 
poly.xCOlJ=matrixCyshitt+1Joxshift+VIEW_LIMIT+1 J+xXWINDOW; 
poly. ¥LOJ=toplyshift+l J+¥WINDOW: 
poly. xl 1J=matrixlyshift4+lICxshi ft+VIEW LIMIT I+XWINDOW ; 
poly. ¥llJ=toplyshift+1J+¥WINDOW; 
poly. yleJ=bottomlyshift+1J+1WINDowW; 
poly. yL3J=bottomlyshift+1J+YWwINbow: 
polydrawt&poly,vleft+xXWINDOW, WINDOW, vright+XWINDOW, 

TWINDOW+WHEIGHT,2,5creen); 


and the view over the righthand portion of the current square: 


poly.xlOJ=matrixCyshift+lJCxshift+VIEW_LIMITI+XWINDOW: 
poly. ¥COJ=toplyshift+] 1+¥WINDOw: 
poly. xClJ=omatrixCyshifti(Cxshi ft+VIEW_LIMITI+XWINDOW; 

















Figure 5-13 The video output from the program POLYCLIP.CPP 
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poly.y0C1J=toplyshift]+¥WwINbow; 

poly. ¥C2J=bottomlyshi ftJ+VWINDOW ; 

poly. yC3lJ=bottomlyshift+1J+7wInbow; 

polydraw(Bpoly,vleft+eWINDOW, YWINDOW,vright+XWINDOW, 
YWINDOW+WHEIGHT,2,5creen): 


The New drawmaze() Function 


The text of the polygon-based version of the @rawmaze() function appears in 
Listing 5-5: 





Listing 5-5 The polygon-based drawmazel) function 


Void drawmazelint xshift,int yshift, int lview,int rview,char *screen) 


// Recursive function to draw Left, right and center walls for the 

ff maze square at POS.X+XSHIFT, POS.Y+Y¥SHIFT, as viewed from POS.%, 
// POS.Y, within the screen window bordered by horizontal coordinates 
// LVIEW and RVIEW on the Left and right respectively. When called 

/f with MSHIFT and YSHIFT set to 0, draws entire maze as viewed 

ff from POS.4,P0S.¥ out to VIEW_LIMIT squares. 


{ 
int vleft,vright,vwwidth; 
polytype poly; 


ff Return if we've reached the recursive Limit: 
if (Cabs(xshift) > VIEW_LIMIT) || Cabs(yshift) > VIEW_LIMIT)) 
return; 


ff Calculate coordinates of square to left: 
int sx = pos.x #* (xshift+l) * left€dird.x + yshift * forward[dir].x; 
int sy = pos.y + (xshift+l) * leftCdir].y + yshift * forward{dirl.y; 


// Get Left-right extent of Left part of view: 
Wleft=lview; 
wright=matrixCyshift+1I[Cxshi ft+VIEW LIMIT+11; 
if (yvright=rview) vright=rview; 
vwidth=vright=vLleft; 


if (wwidth>=0) ¢ 


// lf the square to the Left is occupied, 

// draw right side of cube: 

if (mazeCsxJCsyl) ¢f 
poly. xCOlJ=matrixfyshifti0xshift+vIEW_LIMIT+1]+xXWINDOW; 
poly. yCOJ=topLyshiftl+TWwINbow; 
poly. xC1J=matrixlyshiftt+1 J Cxshitt+VIEW_LIMIT+1I]+XWINDOW; 
poly. y01J=toplyshi ft4+1I+1WwIndow; 
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poly.yl2J=bottoml yshitt+ J+7wINbow; 
poly. yl3J=bottomLyshi ft J+*WINDOW; 
polydraw(&poly,vleft+XWINDOW, WINDOW, vright+ZWINDOW, 
YWINDOW+WHEIGHT,¢,screen); 
} 


ff Else call function recursively to draw the view from 
// next square to the Left: 
else drawmaze(xshift+1,yshift,vleft,vright,screen) ; 


} 


// Calculate coordinates of square directly ahead: 
sx = pos.x + xshift * Leftldirld.« + Cyshift+l) * forwardl[dirl.x; 
sy = pos.y + xshift * leftEdirl.y + Cyshiftt+l) * forward[dird.y; 


‘i Get Lleft=right extent of center part of view: 
vleftsmatrixCyshift+l I[xshift+VIEW_LIMIT+11; 
vright=matrixlyshi ft+lICeshi ft+VIEw LIMITI; 

if (vleft<lview) vleft=lview; 

if (vright=rview) vright=rview; 
vwidth=vright-vLleft; 


if (vwidth>Q) f 


ff If the square directly ahead is occupied, 

‘/ draw front of cube: 

if (mazeCsx]Csyl) ¢{ 
poly. xCOJ=matrixCyshi ft+1TICxshift+ViEW LIMIT+11+XWINDOW; 
poly. yCOlJ=stoplyshift+1]+YWwINnbow: 
poly. xCll=matrixCyshift+Ti Cxshift+VIEW LIMITI+XWINDOW; 
poly. yLlJ=topLyshi ft+1]+V¥WINDOow; 
poly. yC2J=bottom[Eyshift+1]+TWINbow; 
poly. yC3J=bottomlyshift+1lJ+ window; 
polydrawl&poly,vleft+XWINDOwW, FWINDOW, vright+XWINDOW, 

YWINDOW+WHEIGHT,2,screen); 
} 


‘/ Else call function recursively to draw the view from 
‘/ mext square forward: 
else drawmaze(xshift,yshift+1,vleft,vright,screen) ; 

} 


ff Calculate coordinates of square to right: 

Sx = pos.x + (xshift-1) * left€dirjJ.x + yshift * forward[dirl.x; 
sy = pos.y + (xshift-1) * LeftCdird.y + yshift * forwardl[dird.y; 
/f Get Left-right extent of right part of view: 
vlett=matrixlyshiftt+tlILxshi ft+VIEWw LIMITI; 

if (vleft<lLview) vleft=lview; 

Wright=rview; 
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¥width=vright-vleft; 
if (wwidth=0) f{ 


// If the square to the right is occupied, 

// draw left side of cube: 

if (mazeCsxJCsylJ) £ 
poly. xCOJ=matrixzlyshitt+l Ioxshitt+VIEW_LIMITIJ+XWINDOW: 
poly. ¥lLOJ=toplyshi ft+1JI+YWINDow; 
poly.xCll=matrixlyshiftiixshift+VIEW_LIMITJ+XWINDOW; 
poly.yC)J=toplyshiftJ+1WINDOW; 
poly. ¥l2J=bottom[yshiftJ+7WINbOwW; 
poly. ¥C3lJ=bottomlyshi ft+1J+7WINDOW; 
polydraw(Spoly,vleft+XWINDOW, YWINDOW, vright+XWINDOW, 

TWINDOW+WHEIGHT,2,screen}; 
} 


/f Else call function recursively to draw the view from 
// next square to the right: 
else drawmaze(xshift-1,yshift,vleft,vright,screen) : 


Touring the Polygon Maze 


You can try out the complete POLYMAZE.CPP program by CDing to the 
POLYGONS directory from the distribution disk thar came with this book and 
typing POLYMAZE. Once the program is running, you can walk through the 
polygon-based Maze the Salle Waly that you moved through the bitmapped maze 
in chapter 4. by usin the ck TDC keys Ofl the keyboard OF moving the MMOuUsC. 
However, youll notice that this maze is nowhere near as visually interesting as the 
bitmapped maze in chapter 4 was. The walls are a uniform green color and its 
difficult to determine where one corridor ends and a side corridor begins. The 
output from this program is shown in Figure 5-14. 

Must we sacrifice realism in order to build a polygon-based maze? Not 
necessarily, There are several ways in which this maze could be made more 
interesting, though we dont have space in this book to try them all. One would 
be to assign different colors to different wall segments. The palette numbers for 
these colors could be placed in the maze// array instead of the Os and 1s that 
we ve been using since chapter 2. Or we could change the intensity of the wall 
colors depending on how much light is falling on them. If we assume that all 
light comes from a terch or lantern being held by the player, walls at a greater 
distance from the player would be more dimly illuminated than walls thar are 
closer, and walls turned at an angle To the player would be more dimly 
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Figure 5-14 [he video output from the program POLYMAZE CPP 


luminated than walls that face the plaver head on. This technique is called 
lightsourcing, and we ll be studying it in more detail in a later chapter. 

For now, well concentrate on yet another method of making the walls appear 
more interesting and realistic. This technique will allow us to place actual 
bitmaps on the walls and rotare those birmaps along with the walls. In the next 
chapter, we ll take a closer look at texture mapping. 
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olid-colored polygons are boring. While they may be adequate 
for producing the distant scenery visible through the window of 
a simulated airplane, filled polygons just dont cur it as a method 
of drawing du NPcor walls. 





Fortunately, solicl colors arent the only thing that we Can All 
sale with. We can also fill polygons with bitmaps. If we want to create the 
lusion of an ivy-covered brick wall, we can fill our polygon-based dungeon walls 
with bitmaps depicting bricks and ivy. If we want to create a window that looks 
out of the dungeon Onto the rolling countryside, then We Can fll FI polygon with 
a bitmap of a window. And so on. 

So how do we go about filing a polygon with a bitmap? Do we simply copy 
the bitmap byte by byte into the polygons interior? 

Not quite. In order to make the illusion complete, the bitmapped tmages must 
appear to grow smaller as the polygons recede into the distance and larger as we 
grow closer co them. And they must appear to rotate when the polygons rotate. 
Pulling off such an effect requires a bit more programming trickery than simply 
hlling a polygon with a solid color. To graphics programmers, this trickery is 
known as texture mapping. 
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Two-and-a-Half-Dimensional 
Texture Mapping 


Mapping a biemap onto a three-dimensional polygon is, in a sense, a two-step 
process. The bitmap must be scaled for distance, as the polygon grows larger and 
smaller, and the bitmap must be rotated when the polygon rotates, Scaling is the 
easier of the two steps. To scale a bitmap, all you need to do is selectively add and 
remove pixels as you copy the bitmap to the video butter, thus making the image 
appear to grow larger and smaller. Rotating the bitmap, on the other hand, can 
be a great deal more difficult, especially if the polygons on which you are 
mapping the bitmap can rotate on all three axes. 

Fortunately, as we noted in the last chapter, the polygons in a maze game don't 
really need to rotate on all three axes. They only need to rotate on their y axes. 
This greatly simplifies the task of mapping bitmaps onto the polygons. In a sense, 
what we will be doing in this chapter isnt three-dimensional texture mapping. It 
is two-and-a-half-dimensional texture mapping. 


The Two-Step Program 


Because it is the simpler of the two steps, we'll start by discussing the scaling of 
bitmaps. As noted above, this is a relatively simple matter of adding and 
subtracting pixels from the bitmap, to make it appear to grow larger and smaller, 
The most difhcult part of this process is deciding when to add pixels and when to 
subtract them. 

In a few specific instances, this decision is quite easy to make. [f we wanted to 
double the size of a bitmap, for instance, we would simply repeat every pixel (and 
every line of pixels) nwice. And to halve the size of a birmap, we would remove 
every other pixel (and every other line of pixels). But what do we do if we want 
to increase the size of a bitmap to, say, 137 percent of its original size? 

The solution is to turn to our old friend incremental division. So far, we've 
used incremental division to draw lines and to find the upper and lower edges of 
a filled polygon. Now we're going to use it to scale bitmaps, 

To demonstrate, well create a simple program that will scale the familiar 
bitmap depicted in Figure 6-1. You'll find this image in the texture directory as 
MOWNA.TGA. The background over which it will be displayed is in 
MONABG. TGA. 
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Bitmap Scaling 
The bitmap-scaling demo will begin with a few constant definitions: 


const FRAMES PER_SECOND=2; // Animation speed 


const IMAGE _X=25; // Location of bitmap in TGA FILE 
const IMAGE_Y=21; 

const IMAGE WIDTH=76; ff Width of bitmap before scaling 
const IMAGE _HEIGHT=96; ff Height of bitmap before scaling 
const SCREENK=20; // Screen location for scaled bitmap 


We'll be creating a brief animation of sorts, so we first set the frames-per- 
second rate. The IMAGE_X and IMAGE_Y constants represent the x,y 
coordinates of the upper-left corner of the Mona image in the TGA file and the 
IMAGE WIDTH and IMAGE HEIGHT constants represent the width and 
height of that image. We'll pass this information to the grab() function (which we 
developed back in chapter 4) so thar it can copy the bitmap into an array. Finally, 
we set a constant equal to the x coordinate at which we will be displaying the 
Mona bitmap on the screen. (We dont set a constant for the y coordinate because 
that coordinate will change as the bitmap is scaled.) 

We'll also need a couple of TGA structures, one to hold the image to be scaled 
and one to hold the background image upon which the scaling will take place. 
We'll call these structures mona and bg: 


tga_struct mona,bg 


We also need an array in which to store the portion of the bitmap that we ll be 
“grabbing trom the mona structure: 
char bitmapCIMAGE_WIDTH*IMAGE HEIGHT]; 





Figure 6-1 4 familiar 
bitmapped image 
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The main() function will begin with the usual folderol: setting up a pointer to 
video memory and to an offscreen buffer, saving the old video mode, initializing 
the timer, and setting the video mode 13h. Then we'll load the wo TGA images 
into their respective structures: 
if CloadTGA("mona.tga",&tga)) { 

setmode(aldmode),; 


exittl): 


if CloadTGAC"monabg.tga",&bg)) f 
setmode(loldmode) ; 
exit(1); 

} 


We also need to set the palette, which raises an interesting question: Do we 
use the palette from MONA.TGA or the palette fom MONABG.TGA? As it 
happens, either palette will do. Because these images are designed to be displayed 
together on the screen, it was necessary to use the same palette on both. For some 
tips on how to match palettes between two or more images using only the public 
domain PicLab program, see Appendix A. To set the palette in our program, we ll 
arbitrarily use the palette from MONA.TGA: 


setpalette(mona.color_map); 
We ll continue scaling the image until somebody presses a key: 
while ('kbhit(}) 4 


But before we begin, we'll want to copy the background image (which is 
contained in the mage held of the 4¢ structure) into the screen butter: 


for (unsigned int 1-0; 1<64000; i++) 
screen_butferliJ=bg.imagelid; 


When we scale bitmaps, we'll need both to shrink the bitmaps and to enlarge 
them. To demonstrate how both of these operations are performed, we'll first 
reduce Mona to: 10 percent of her original size, then gradually expand her to 
twice her normal dimensions. We'll use a for() loop to step the percentage of 
reduction from 10 percent to 200 percent, at 5 percent intervals: 


for (int percent=10; percent<=200; percent+=5) { 
This is a good spot to insert a frame delay, so that the scaling doesnt take place 


too quickly. We'll also reset the lastframe variable (which we've used in earlier 
programs) to indicate the time at which the next frame begins: 


while (Cclock()-Lastframe)<ticks_per_frame) ; 
lastframe=clock(); 
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The Vertical Error Term 


We'll draw the image as a series of horizontal lines, one on top of another. (This 
is similar, but not identical, to the way in which we drew polygons as a series of 
vertical lines in the last chapter.) We can scale the image along its horizontal axis 
by adding and subtracting horizontal lines. If the image is to become larger, we'll 
repeat some of the lines two or more times. If the image Is to become smaller, 
we'll subtract some of the lines, We'll use an error term to determine if and when 
lines need to be added or subtracted. Before drawing a pixel, we'll add the value 
of percent to this error term and compare the sum to 100. If the error term is 
equal to or greater than 100, then we'll draw the next row of pixels and subtract 
100 from the error term. We'll keep doing this until the error term is less than 100. 

It's not hard to see how this works. If the value of percent is 50 — that is, if we 
are reducing the image to 50 percent of its original size — percent will need to be 
added to the error term twice before a row of pixels is drawn. This will cause the 
drawing routine to skip every other row of pixels, reducing the image to 50 
percent of its original size in the vertical dimension. (Well be doing the same 
thing in the horizontal dimension, as you'll see in a moment.) If percent is equal 
co 200, we'll need to subtract 100 from the error term twice before its value 
becomes less than LOO, so every row will be drawn twice. Values berween these 
extremes will scale the image to 20 percent, or 75 percent, or 150 percent, or 
whatever percent of its original size. 

We'll call this error term yerrer, because it will be used for scaling on the y axis: 


int yerror=0; 


Earlier, we established the x position at which well draw the scaled image, bur 
not the y position. That's because we want to adjust the y position as the image is 
scaled, When the image is small, we'll put it near the vertical center of the 
display, As it increases in size, well move it up the screen so that the bottom of 
the image wont run past the end of the screen buffer, We can use the percent 
variable to calculate a reasonable y position and store it in the integer variable 
sereeny: 
int screeny=(200-percent)/2; 

Before we can begin drawing, we need to know the offset in video memory at 
which the pixel in the upper-left corner of the scaled image is to be drawn. The 
coordinates of that corner are stored in the constant SCREEN and the variable 
screeny. From these, we can calculate the offset using the standard formula and 
store it in the unsigned integer variable serper: 


unsigned int scerptr=screeny*3520+S5CREENX: 
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We also need to know the offset into the Sfmap array of the next pixel in the 
original image. This pixel may or may not actually be drawn, depending on the 
current scaling percentage. We'll store the offset in the unsigned int variable 
bitptr: 
unsigned int bitptr=0; 


Because we ll be drawing the bitmap as a series of horizontal lines, we'll use a 
fort) loop to loop through all the lines in the bitmap: 


for (int y=0; y<IMAGE_HEIGHT; y++) f 


Should we draw che next row? Or should we skip over it to reduce the size ot 
the bitmap? That depends on the value of yerror. We'll add the percentage value 
to yerror, then check to see tt it's greater than 100: 
yerror+=percent; 


while (yerror>100) ¢{ 
yerror-=100; 


If the error term is equal to or greater than 100, we'll subtract 100 from it and 
start drawing the row, We use a w/tle() statement here rather than an #/f), so that 
the loop will he executed more than Once if yerrar 15 still Preater than 100 after 
100 has been subtracted from it. This will only happen if percent is greater than 
100 and will CaLsc the pixel to be drawn more than Once in Succession. This will 
make the pixel appear wider than it normally would, increasing the vertical size 
of the drawing (which is appropriate when the percentage is greater than 100). 

Before we can begin drawing pixels, there are a few details to take care of. The 
first is to record the value of serptr (which, as you recall, contains the current pixel 
offset in the screen buffer) in a variable called ofd_serptr. We'll use this value later 
TO calculate the offset for the Next POW ot pixels to be drawn, cl you ll sce in el 
moment: 


unsigned int old_serptr=scrptr; 
We'll also need to save the value of bftptr, which contains the current offset in 
the pixel buffer, in a variable called old_bitper: 


unsigned int old_bitptr=bitptr; 


The Horizontal Error Term 


Just as we used an error term to determine which pixels in a row are to be 
repeated and which are to be skipped, we ll also use an error term to determine 
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which columms of pixels are to be repeated and which are to be skipped. Because 
it will be used to scale the image on its x axis, we ll call this integer variable xerrer: 


int xerror=0; 
Well use a for() loop to iterate through all of the pixels in the row: 
for Cint x=0; x<IMAGE_WIDTH; w++) 


On each iteration, we'll add 100 to xerrer to determine if we should draw the 
next pixel. If xerrer is greater than 100, well draw the pixel and subtract 100 
from xerror — and well continue drawing the pixel and subtracting 100 until 
xerror is less than 100: 
xerror+=percent; 


While (xerror>100) ¢ 
yerror-=100; 


Drawing a Pixel 

After one heck of a lor of preparation, we are finally ready to draw the next pixel, 
This is a simple matter of copying the pixel value at offset Gitprr in the birmap 
array to the position in the screen buffer pointed to by serper: 


screen_butfferlscrptrl=mona.imagelbitptrd; 


That being done, we can increment serprrto point to the position at which the 
next pixel will be drawn and end the innermost while() loop, the one that repeats 
the pixel drawing if the scaling percentage is greater than 100: 


scrptr++; 
} 


We deliberately do not increment #itptr to point at the next pixel in the 
bitmap butter, because Wit may need To draw the CLUrrent pixel More than Once. As 
soon as the innermost wiile(} loop stops executing, however, we move éitpir 
forward by one and terminate the jor() loop that draws the row of pixels: 

bitptr++; 
} 

The current row of pixels has now been drawn, We'll advance serper to the next 
row of pixels on the display. The easiest way to do this is to take the oftset of the 
first pixel in the row just finished and add 320 (the width of the display) to it. 
Fortunately, we stored the offset of the first pixel of the row in the variable 


old_serptr: 
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scrptr=old_scrptr+320; 


If the current row of pixels in the ditrnap bufter is being drawn more than 
once (that is, if the value of percent is greater than 100), well need to reset bitper 
back to the first pixel in the row. We've stored the offset of that pixel in the 
variable ofel_bitptr: 


bitptr=old_bitptr; 
} 


And that ends the while() loop that draws the rows of pixels, repeating them if 
necessary. We now must advance #itptr to the next line of pixels in the bitmap 
and end the for() loop that iterates through all of the rows of the image. 
Advancing frtpir is easy, since we've just reset it to the beginning of the last row. 
All we need to do is add the width of the bitmap to it 


bitptr+=IMAGE_WIDTH: 
+ 


The sealed bitmap has now been drawn, but well need to move the contents 
of the screen buffer into video memory so that the user can see the drawing. 
Then we'll close all outstanding loops: 


blitscreen(screen_buffer); 


The BITSCALE.CPP Program 


Theres nothing left to do at this point except restore the old video mode and end 
the program. Weve done this in so many programs now that we dont need to 
show the details, The complete text of BITSCALE,CPP. however, appears in 
Listing 6-1: 





Listing 6-1 The BITSCALE.CPP program 


f/f BITSCALE.CPP Version 1.0 

‘/ Seales a bitmap on the mode 13h display 

if 

ff Written by Christopher Lampton 

i for GARDENS OF IMAGINATION (Waite Group Press) 


Hinclude <stdio.h> 
Hinelude <dos.h> 
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finclude <conio.h> 
#include <stdlib.h> 
finclude <time.h> 
Hinclude “screen.h" 
include “targa.h” 
finclude "“bitmap.h" 


fdefine FRAMES _PER SECOND 2 


Const 
const 
const 
const 
const 
const 


IMAGE_X=25; 
IMAGE_Y=21; 
IMAGE WIDTH=/6; 
IMAGE_HEIGHT=96; 
SCREENX=20; 
SCREENY=0; 


Long ticks_ per_frame; // Number of clock ticks per 


ff frame of animation 


tga_struct mona,bg; 
char bitmaplIMAGE_WIDTH*IMAGE_HEIGHT]; 


void maint) 


{ 


‘if Create pointer to video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


// Save previous video mode: 


int 


oldmode=*(Cint *)MK_FP(0x40,0x49); 


// Create offscreen video buffer: 
char far *screen_butfer=new unsigned char [é4000); 


// Put display in mode 13h: 
setmode(Qx13); 


// Set number of ticks per frame: 
ticks _ per_frame = CLK_TCK / FRAMES PER SECOND: 


‘f Initialize the frame timer: 
clock_t lastframe=clock(); 


‘/ Load bitmap from TGA file: 
if (LoadTGAC"mona.tga",&mona)) f 


} 


setmodeioldmode) ; 
exit(l); 


if C(loadTGAC"monabg.tga",&bg)) f 


setmodeloldmode) ; 


Texture Mapping 
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exittl); 
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/* Set palette to TGA palette: 
setpalette(mona.color_map); 


/f Keep Looping until somebody hits a key: 
while ('kbhitt)) f{ 


ff Copy background image to screen buffer: 
for funsigned int i=0; 1<64000; i++) 
screen_bufferlil=bg. imageLlil; 


ff Expand picture from 10 to 200 percent: 
for Cint percent=10; percent<=200; percent+=5) ft 


/f Pause until time for next frame: 
while ((€clockC)-Lastframe)<ticks  per_frame) ; 


ff Start timing another frame: 
Llastframe=clock(}; 


ff Initialize vertical error terms: 
int yerror=0; 


int screeny=(200-percent)/2; 


ff Offset of first screen pixel in row: 
unsigned int scrptr=screeny*320+S5CREENK ; 


ff Offset of Tirst Bitmap pixel dn row: 
unsigned int bitptr=0; 


‘/ Loop through rows of bitmap: 
for Cint y=0; y<IMAGE_HEIGHT; y++) f 


f/f Should we draw next row? 
yerrort=percent ; 


ff If so, repeat row until done: 
while Cyerror>100) { 


if Reset error term: 
yerror=-=100; 


‘/ Save screen row offset: 
unsigned int old_secrptr=scrptr; 


// Save bitmap row offset: 
unsigned int old_bitptr=bitptr; 


ff Initialize horizontal error term: 
int xerror=0; 





CHAPTER SIX Texture Mapping 


ff Loop through pixels in row: 
for (int x=0; x<IMAGE WIDTH; x++) 4 


// Should we draw mext pixel? 
xerrort=percent; 


ff If so, Loop through all rows to be drawn: 
while (xerror>100) { 


/f Reset error term: 
xerror-=100; 


ff Copy next pixel from bitmap to screen: 
screen_butferCscrptrJ=mona.imagelbitptrd; 


ff Point to next pixel on sereen: 
scrptrt+; 
} 
ff Point to next pixel in bitmap: 
bitptr++; 
} 


/f Point to next row on screen: 
scerptr=old_scrptr+320; 


‘/ Repeat same row in bitmap: 
bitptr=old_bitptr; 
} 


‘/ Point to next row in bitmap: 
bitptr+=IMAGE_WIDTH; 
} 


// Move screen buffer to screen: 
blitscreen(screen_ buffer); 
} 
} 


while ('kbhit()); 


// Release memory 

delete bg. image; 

delete bq.color_map; 

if (bg.ID) delete tgaliiJ.Ib; 
delete mona. image; 

delete mona.color_map; 

if (mona.ID) delete mona.ID; 
screen_butfer; 


/f Restore old video mode: 
setmodeloldmode} ; 
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Running the Program 

To see BITSCALE.CPP in action, go to the directory called TEXTURE and type 
BITSCALE. Youll see Mona go from small to large, as in Figures 6-2a through c, 
then back to small again, To stop the process, hit any key, though the program 
wont acknowledge your request until it has run through a complete scaling cycle. 


Texture Mapping 


Now that weve seen how to scale an image, were ready to develop some more 
versatile texture-mapping code. Surprisingly, the complete texture-mapping 
function will use the same principles of bitmap scaling that we just used to create 
BITSCALE.CPP to perform both the scaling and the rotating of polygons, By 
limiting ourselves to a subset of all polygons, the way we did in the polygon- 
drawing function in the last chapter, we will be able to reduce texture mapping to 
a simple scaling system, where the polygon is drawn as a series of vertical lines, 


each of which ean be sealed individually. 
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The Ground Rules 

Lets set out some ground rules for the type of texture mapping that well be 
doing in this chapter. First, we are only going to work with rectangular bitmaps. 
This may seem like an obvious starement, since bitmaps are almost always 
rectangular, buc in texture mapping there are some advantages to working with 
bitmaps that have nonrectangular shapes, especially if the polygon onto which 
the bitmap is being mapped has the same nonrectangular shape. Were not going 
to worry about such special cases in this book, however. 

Second, the polygons onto which we will be mapping these bitmaps will 
always have four vertices, as the polygons we generated in the last chapter did. 
And the left and right edges of those polygons will always be vertical. Further, 
each corner of the bitmap to be mapped onto the polygon will correspond to an 
equivalent corner of the polygon. Thus the upper-left corner of the bitmap will 
correspond to the upper-left corner of the polygon, and so forth. Figure 6-3 
shows the relationship between a rectangular bitmap and a four-sided polygon. 

The surprising thing about mapping bitmaps to this limited subset of 
polygons is that we dont need to know anything about the way in which the 
polygon has been rotated in order to map the texture onto it. All we need to 
know are the x,y coordinates of the four corners of the polygon. (In fact, we dont 
even need to know the x coordinates of the two lower corners of the polygon, just 
as we didnt need to know these coordinates when we were drawing hlled 
polygons in the last chapter.) Once we know those coordinates, we can draw the 
polygon as a sequence of vertical lines, as in chapter 5. Bur instead of drawing 
each line in a solid color, we will copy the bitmap pixels from the equivalent 





Figure 6-3 Each of the corners.of the 
bitmap will correspand to one of the 
corners of the polygon 
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vertical line in the texture map, skipping or repeating pixels as necessary to match 
the length of the vertical line of pixels in the texture map to the length of the 
vertical line in the polygon. In effect, we will be performing a separate scaling 
operation on each vertical line copied from the bitmap to the polygon. (We'll also 
be skipping or repeating entire vertical lines, as necessary to scale the texture 
horizontally.) Not surprisingly, we'll use a pair of error terms to determine the 
precise amount by which the texture map needs to be scaled in the horizontal 
and vertical dimensions. 


The Texture-Mapped Polygon Function 

To draw texture-mapped polygons, well write a function called polytext(), which 
will be similar to the poldraw( ) function that we developed in the last chapter. 
This function will be placed in the fle POLYTEXT.CPP. The prototype for the 
function, which will be placed in the fle POLYTEXT.H, looks like this: 


void polytext(tpolytype *tpoly,int Leftx,int Lefty,int rightx, 
int righty,char *screen) 


You'll note that these parameters are similar to the ones passed to the 
polydraw() function in the last chapter. The integer variables deftx, lefty, rightx, 
and righty define the x,y coordinates of the upper-left and lower-right corners of 
the viewport that the polygon is to be clipped against. There's no color parameter 
passed to the function, because we wont be filling the polygon with a solid color. 
The description of the polygon itself is passed to the function in a structure of 
tpolytype. Similar to the pelytype structure that we used in the last chapter, 


tpolytype is defined in POLYTEXT.H like this: 


struct tpolytype f 
int xC4J; 
int yC4I; 
int wtext; 
int fhtext; 
char *textmap; 
}; 


The xand y arrays work just like they did in the polytype structure, holding the 
x and y coordinates of the four corners of the polygon, starting at the upper-left 
corner and proceeding counterclockwise around the shape. [he wrext and /text 
felds contain the width and height, respectively, of the rectangular bitmap to be 
mapped onto the polygon. The pointer variable textmap points at the array of 
type cbar that contains the bitmap to be mapped onto the polygon. 

The actual polygon drawing ts handled in much the same way as it was in 
polydraw(). However, there is additional code here to handle the texture mapping. 
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Since weve already covered the polygon-drawing algorithm in chapter 5, we'll 
skip over that part of the function and discuss the texture-mapping additions. 

At the beginning of the function, we create a pointer into the texture map 
array, which will initially be set to 0: 


unsigned int tptr=0; 


We then check to see if the polygon crosses the left edge of the viewport, as in 
Figure 6-4, [fit does, we clip it, However, in addition to clipping the polygon as 
we did in chapter 5, we must also clip the texture — that is, we must reposition 
the gper variable so that it points nor at the first pixel in the texture map, but at 
the first pixel that falls within the viewport. To hnd the new position for tprr, we 
calculate three integer values: wtemp (which contains the width of the unclipped 
polygon), offtemp (which contains the width of the portion of the polygon that 
extends beyond the left edge of the viewport), and netic (which represents the 
ratio of the width of the polygon to the width of the texture to be mapped onto 
the polygon): 
int wtemp=tpoly->xC1J-tpol y->xC0]+1; 


int offtemp=leftx-tpoly->x(0J; 
float xratio=(float)tpoly-swtext/wtemp; 


What are we going to do with these values? We need to calculate how much of 
the texture map will extend beyond the left edge of the viewport. Unfortunately, 
this isnt necessarily the same as the portion of the polygon that extends beyond 
the left edge of the viewport. We'll be sealing the birmap to ft the polygon, so 
one pixel in the bitmap may be equivalent to several pixels in the polygon — or 
vice versa. The ratio variable tells us what the actual scaling ratio will be. IF it's 





Figure 6-4 A polygon overlapping the 
left edge of the viewport 
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less than 1, then we will be increasing the size of the texture map to fir the 
polygon, If it's more than 1, then we will be reducing the size of the texture map. 

For now, though, we'll just multiply natie by the portion of the polygon that 
extends off the lefthand side of the viewport to get the number of bitmap pixels 
that would have been mapped into that portion had we been drawing it. We can 
then advance ¢pir past this portion of the bitmap: 


tptr=offtemp*xratio; 


We must also subtract chis value from the weve feld, which contains the width 
ot the CEXTUITC tat po, To ee the clipped width ot the iC#xXTwUTEe Map. 


tpoly->wtext-=tptr; 


We then proceed to clip the polygon itself, just as we did in the polydnaw() 
function. Before we can begin the actual drawing, though, we'll pur the height 
and width of the texture Map inte a pair of Integer variables, so that we don't 
need to continually reference the tpely structure to get those values. (This may or 
may not speed up the program slightly, depending on how intelligently the 
compiler translates our high-level instructions into optimized machine code.) 
int theight=tpoly->htext; 
int twidth=tpoly->wtext; 

We also need to create a pair of error terms that will tell us when it’s time to 
advance vertically and horizontally in the texture map. First well create the 
horizon tal CIror Teri, which we Ll call iMerrer: 


int txerror=0; 


Next, well initiate a for’) loop that will step across the entire width of the 
polygon, just as in polydraw(). However, at the head of this loop, well create a 
variable called ¢ that will serve as a pointer into the texture map. (The ¢prr 
variable also serves this function, but we'll need to preserve the current value of 
tptr tor later use.) 


int t=tptr; 
As before, we'll clip the polygon against the top edge of the viewport. This 


time, however, we'll also need to clip the texture. First we'll calculate the ratio of 
the height of the bitmap to the height of the polygon: 


float yratio=(float)tpoly=<>htext/herght; 
Then well multiply this ratio by the portion of the polygon that extends 
above the top edge to calculate how much of the bitmap extends over that edge: 


te=(lLefty-y)*yratio; 
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After the clipping of the polygon and texture Map are complete, we ll establish 
yet another error term to help us scale the texture in the y dimension: 
int tyerror=0; 

Now we begin the for(/ loop that draws the vertical column of pixels, just as 
we did in polvadraw(). However, instead of setting each pixel in the column to a 
single color, we copy a pixel from the texture map into video bufter: 
screenLptrJ=tpol y—>textmapltl; 

Should we now advance to the next pixel in the texture map? That depends on 
the value of Fyerrar: 
while (tyerror<theight) { 

If the value of yerror is currently less than the height of the texture map, we 
add the height of the pixel column to tt: 


tyerror+=height: 


and advance the texture map pointer to the next line: 
tt+=twidth; 


We continue advancing the pointer as long as the value of tyerror is less than 
theight. When the texture map needs to be reduced in size, this while() loop will 
execute more than once, skipping the pointer over the pixels that need to be 
omitted, If the texture map needs to be expanded, this while() loop will only 
execute on same passes through the drawing loop, causing pixels to be drawn 
more than Once, When the value ot ot terror becomes preacer than theight, the 
loop terminates and we subtract terght from the error term so that the process 
can begin once more: 


tyerror-=theight; 
Once the vertical column of pixels has been drawn, we must decide whether to 


advance to the next column, skip a column, or repeat the present column. The 
error term txverror helps us make this decision: 


while (txerror<twidth) { 
lf txerror is less than the width of the texture map, we add the width of the 
polygon to txerrer and advance tpfr to point to the next column of pixels: 


txerrort+=width; 
tpirt+; 
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We continue doing this until the value of tverrer 1s greater than «wrath. This 
determines whether the column of pixels 15 skipped or repeated. Once teerrer 1s 
greater than fwidth, we subtract twialth from it and close the loop: 


txerror-=twidth; 


The polytextQ) Function 


A listing of the complete polytext() function appears in Listing 6-2. 





s Listing 6-2 The polytextt) function 


Finclude <stdio.h> 
Hinclude <math.h> 
finclude "polytext.h" 


// Function to draw a texture mapped polygon defined by 

// polytype parameter POLY clipped against a viewport with 
// upper Lefthand coordinates of LEFTX,LEFTY and Lower 

ff righthand coordinates of RIGHTX,RIGHTY. 


void polytext(tpolytype *tpoly,int Leftx,int lefty,int rightx, 
int righty,char *screen) 
{ 
float tslope,bslope; 
int vwidth,vy,vheight; 


ff Initialize pointer into texture map array: 
unsigned int tptr=0; 


ff If polygon crosses Left side of viewport, clip it: 
if (tpoly->x[Ol<leftx) ¢ 


// Caleulate offset of clip in texture map array: 
int wtemp=tpoly->x01)]-tpoly->xCOJ+1; 

int offtemp=leftx—-tpoly—>xl0]; 

float xratio=(float)tpoly-swtext/wtemp; 
tptr=offtemp*xratio; 

tpoly->wtext-—=tptr; 


‘/ Calculate slopes for top and bottom edges: 
tslope=(float)(tpoly—->yl1J-tpoly->yC01)/(tpoly->x01J-tpoly—>xC0]); 
bslope=( float) (tpoly->y[3]-tpoly=>y02])/ Ctpoly->xC0J-tpoly->xl1]) ; 


‘i Find new endpoints for clipped Lines: 
tpoly->yLOJ=tpoly->y(OJ+tslope*( lLeftx=tpol y->x[0]); 
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tpoly->yC3J=tpoly->y[3]+bstlope*(lLeftx-tpoly->xf0]); 
tpoly—->xlO0l]=leftx; 
} 


ff Initialize x,y coordinates for polygon drawing: 
int x=tpoly=>xC01: 
int y=tpoly->yC0]; 


ff Calculate the change in y¥ coordinates Tor top 
// and bottom edges: 

int topdiff=tpoly—>y[11-tpoly->y[0I; 

int botdiff=tpoly->yl2]-tpoly->yC3J; 


ff Initialize height and width of clipped polygon: 
int height=tpol y->yC3J-tpoly->y¥CO1; 
int width=tpoly->xC1J-tpoly=->xCO0)+1; 


f/f Clip polygon width against right side of viewport: 

if (tpoly->x01]>rightx) 
vwidth=width-(tpoly->x01J-rightx); 

else vwidth=width; 


// Inittalize height and width of texture map: 
int theight=tpoly->htext; 
int twidth=tpoly=>wtext; 


ff Initialize top and bottom error terms: 
int toperror=0; 
int boterror=(; 


‘f Initialize horizontal error term for texture map: 
int txerror=0; 


// Loop across width of polygon: 
for (int w=0; wevwidth; wet) { 


/f Initialize temporary offset into texture map: 
int t=tptr; 


ff If top of current vertical Line is outside of 
/f viewport, clip it: 
if Cy<Lefty) f 
vy=Lefty; 
vheight=height-(lefty-y); 
float yratio=(float)tpoly->htext/height; 
te=(Lefty=-y)*yratio; 
} 
else { 
VY=¥; 
vheight=height; 
} 
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if ((vy+tvheight)>righty) 
vheight=righty-vy; 


ff Point to video memory offset for top of Line: 
unsigned int ptr=vy*320+x; 


ff Initialize vertical error term for texture map: 
int tyerror=0; 


// Loop through the pixels in the current vertical 

‘f/f Line, advancing PTR to the next row of pixels after 

ff each pixel is drawn. 

for(int h=0; h<vheight; h++) { 
screenLptri=tpoly->textmapltJ; 


ff Ts it time to move to next row of pixels in map? 
while (tyerror<theight) f 
tyerror+=height; 
t+=twidth; 
} 
tyerror=-=theight; 
ptr+=3520; 


F 


/f Advance x coordinate to next vertical Line: 
toperrort+=abs(topdiff); 


/f If so move it up... 
while (toperror>=width) f 


ff If so move it up... 
toperror-=width; 
if (topdiff>0) f 
yet 
=—-height; 
} 
else f{ 
“=e 
hetgnt++; 
} 
} 
boterror+=abs(botdiff) ; 
while (boterrorz=width) f 
boterror-=width; 
if (botdiff>0) height++; 
else —-height; 
} 


Is it time to move to next pixel column in map? 
while (txerror<twidth) { 

txerrort+=width; 

tptr++; 
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} 
txerror-=twidth; 
} 
} 


A Textured Polygon Demo 
To test this function, well rewrite the POLYDEMO.CPP program from the last 
chapter as TEXTDEMO.CPP The changes will be minor. We'll create a TGA 
structure to load a bitmapped Image Inte: 
pex_ struct wall; 

What bitmap will we use? Lets try using one of the birmapped images from 


our earlier bitmapped maze program. Specifically, well use a portion of the image 


from FRONT 1.TGA: 
if (LoadTGA("frontl.tga",fwall)) exitt1); 

Now let's allot some memory in the ¢poly structure to store the portion of the 
bitmap that we ll be “grabbing” our of FRONT1,TGA: 
tpoly.textmap=new charl95*/9]; 

What portion of the bitmap should we grab? Let's go for the portion thar 
shows a. complete wall sCement: 
grab(4/7,20,95,/79,pcx. image, tpooly. textmap) >; 

The rest of the code is identical to that in POLYDEMO.CPP. except that 
when we set up the gpoly structure to be passed to the fextdemo() function, we 
must include values for the width and height of the bitmap: 


tpoly.wtext=95; 
tpoly. htext=r9; 
polytext(&tpoly,40,40,95,175,screen); 


The TEXTDEMO Program 
The complete text of the TEA TDEMO.CPP program appears in Listing 6-3. 





==te: Listing 6-3 The TEXTDEMO.CPP program 


Hinclude <stdio.h> 
Finclude <dos.h> 
finclude <conio.h> 
Kinclude <stdlib.h> 
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finclude "screen.h" 
Finclude “polytext.h" 
Finclude "“bresnham.h" 
Finclude "“pex.h" 
finclude "“bitmap.h" 


void drawboxCint Leftx,int lefty,int rightx,int righty, 


char *scereen); 


pcx struct wall; 
char far bitmapl95*79]> 


void maint) 


{ 


if Declare polygon structure: 
tpolytype tpoly,; 


// Load wall bitmap: 
if (LoadTGAt"front].tga",fwall)) exit(1); 


/f Allot memory for wall bitmap: 
tpoly.textmap=new charl95*/9]; 


‘/ Grab wall image in array: 
grab(0,0,95,79,pcx.image,tpoly.textmap); 


f/f Create pointer to video memory: 
char far *screen=(char far *)JMK_FPCOxa000,0);> 


// Save previous video mode: 
int oldmode=*(int *)MK_FP(Ox40,0x49) > 


// Put display in mode 13h: 
setmode{0x13); 


‘/ Set palette to ICEMAP palette: 
setpalette(pcx.palette) ; 


// Clear display: 
cls(screen); 


‘/ Draw box on display: 
drawbox(40,40,95,175,screen); 


tooly.xLOJ=50; 
tpoly.yC0J=50; 
tpoaly.xC1J=100; 
tooly.¥CTJ=H10; 
tpoly.xf2J=100; 
tpoly.yl2J=190; 
tooly.xC3J=50; 
tpoly.¥£3J=150; 
tooly.wtext=95; 
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tpoly Atext="9; 
polytext(&tpoly,60,40,95,175,screen); 


/f Hold polygon on screen until keystroke 
while ('kbhit()); 


‘* Release memory 

delete wall .image; 

delete wall.color_map; 

if Cwall.IB) delete wall.ID; 
delete tpoly.textmap; 


‘f/f Restore old video mode: 
setmodetaldmode) ; 


woid drawbox(int leftx,int Lefty,int rightx,int righty, 
char *screen) 


Linedraw(leftx,lefty,rightx,Llefty,15,screen); 
Linedraw(rightx,lefty,rightx,righty,15,screen); 
Linedrawtrightx,rignty,leftx,righty,13,screen); 
Linedraw(leftx,righty,leftx,lefty,15,screen): 


Running the Program 

To run TEXTDEMO.CPP. go to the TEXTURE directory and type TEX TDEMO. 
A texture-mapped polygon will appear on the display (see Figure 6-5). Try 
changing the polygon and clipping parameters and recompiling the demo, If 
youre really brave, try loading a different birmap and mapping it onto the 


polygon. 





Figure 6-5 4 texture-mapped polygon asdrawn by 
FEXTDEMO.CPP 


fave 
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A Texture-Mapped Maze 


Now that we have a function to draw texture-mapped polygons, lers plug it 
into the POLYMAZE program from the last chapter. The main difference 
between the program TEXTMAZE and the earlier program POLYMAZE ts that 
a texture map is loaded in during initialization (the same one we used in 
TEXTDEMO.CPP) and the pofytext() function is called instead of palyaraw( ) 

In addition, there is a new function in this program called dnewbg(). It draws a 
background image behind the textured polygons. Youll recall that the maze 
images back in chapter 4 contained not only pictures of the walls, but of the floor 
and sky as well. The background image that we'll use for the drtwébg() function 
will come from the fle EMPTY.TGA. It is the image of an empty maze, with 
only floors or ceilings. Well copy this into the viewport with the dmmwbe() 
function, then draw the texture-mapped polygons on top of it: 
void drawbg(int num,char far *screen) 

{ 

unsigned int offsetl=TWINDOW*320+XWINDOW; 

unsigned int offset2=0; 

for Cint i=0; i<WHEIGHT; i++*) { 

for (int j=0; j<WWIDTH; j++) 
screenLof fseti++J=bglnuml. imageloffsete++; 
of fsetl+=(320-WWIDTH) ; 


I 
+ 


The function itself is nothing more than a nested pair of for() loops to copy the 
data from the 7GA_struer holding the floor and sky bitmap into the offscreen 
video buffer, 

The complete text of TEXTMAZE.CPP is shown in Listing 6-4. 





i Listing 6-4 The TEXTMAZE.CPP program 


‘/ TEXTMAZE.CPP Version 1.0 

‘/ An animated tour of a 3D texture-mapped maze 

If 

‘/ Written by Christopher Lampton 

‘i for Gardens of Imagination (Waite Group Press) 


Hinclude <stdio.h> 
Hinclude <dos.h> 
Hinclude <conio.h> 
finclude <stdlib.h> 
Hinclude <time.h> 
4include “screen.h" 
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finclude “io.h" 
Finclude “evntmgrl.h" 
Finclude “bitmap.h" 
Hinclude “pex.h" 
finclude "“targa.h" 
Finclude “polytext.h" 


fdefine FRAMES _PER_SECOND 5 
Fdeftine  WHICH_EVENTS KETBOARD_EVENTS+MOUSE_EVENTS 


ff Function prototypes: 
yoid display slicefint imagenum,int leftx,int rightx, 
char far *screen); 
void drawbglint num,char far *screen); 
void drawmaze(int xshift,int yshift,int lview,int Lrview, 
char *sereen)}; 


const VIEW_LIMIT = 4; // Number of squares visible both 
‘if forward and to the side. 
‘/ (Should not be changed without 
‘/ adding additional bitmaps.) 


const XWINDOW = 170; // Upper Left corner of view window 
const YWINDOW = 0; 

const WWIDTH = 188; 

const WHEIGHT = 120; 


/! Buffers for compass picture and background: 
pcx struct compasses,pcx; 

tga_struct bgl2)],wall; 

char far bitmapl95*79]; 


// Array of compass faces: 
unsigned char far *compass_facel4]; 


‘/ MAP OF THE MAZE 

ii 

ff Each element represents a physical square within the maze. 
‘/ A value of O means the square is empty, a nonzero value 

// means that the square is filled with a solid cube. Map 

‘f/f must be designed so that no square can be viewed over a 

‘/ greater distance than that defined by VIEW_LIMIT. 


unsigned char mazrelL16JL16J=f{ 
Tle be he a bp ale lial ledge ke lee 
{1,0,0, 0,1 ,0,0,0,1,0,0,0,1,0,0,1}, 
{T,0,1,0,0,0,1,0;,0,0,1,0,1,1,0,1F, 
{1,0,1,1,1,1,1,0,0,0,1,0,0,0,1,11, 
{1,0,0,0,0,1,0,0,0,0,1,0,1,0,1,1}, 
{7,0,0,0,0,1,0,1,1,1,1,0,0,0,1,13, 
tt, 4,1,0,0,1,1,0,1,0,0,1,1,0,1,73> 
{1,0,1,0,1,1,1,0,0,0,1,0,0,0,1,1}, 
{1,0,1,0,0,0,1,1,1,0,0,0,1,1,1,11, commmued on met page 
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{1,1,0,0,0,0,1,0,1,0,0,0,0,0,1,11, 
£1,0,00,51,1,1,0,1,051,1,1,0,1,13; 
£1,0,1,1,1,0,1,0,0,0,0,1,0,0,0,1}, 
10,0 007 Ostia ie tele) ple Tas 
{1,17,0,0,0,1,-1,0,0,0,0,1,0,0,0,13, 
sy Bray fread ray rey a: Bs EO PO a Lee i Fs Fy By 

+} 

typedef struct xy 4 
int x,¥; 

}; 


ff Directional increments for north,east,south,west 
‘/ respectively: 

struct xy forward(4J={{-1,0},{0,1},1{1,0},{0,-1)); 
struct xy Leftl4J={{0,-1},{-1,0},{0,1},41,033; 
struct xy right(4]={{0,13,{1,0},{0,-1},{-1,03}; 


/‘f Viewer's starting position: 
struct xy pos={3,5}; 


ff Structure to hold polygon data: 
tpolytype tpoly; 


f/f Horizontal screen positions corresponding to 

ff wisible intersections on the maze grid: 

int matrixCVIEWLIMIT+2IC0VIEW_LIMIT*2+2J={ 
(187, 16f, of, 18f, 187, 0, 0, O, O,. OF, 
118/, 187,187 ,258,145, 47,-49, 0, O, Of, 


{1é7, 187, 187,179,123, 66, 10, 0, OO, OF, 
(187, 187,167,156,117, 73, 31, O, OO, OF, 
£187, 187,177,144,111, 78, 45, 12, 0, O}, 
{187,185,159,133,107, 82, 56, 30, 4, 0} 


i 
int topCVIEW_LIMIT+2]={-19,20,36,42,46,49) > 
int bottomLVIEW_LIMIT+2]=(138,99,83,77,73,7O); 


int dir=1l;) // Viewer's current heading in maze, 
ff where O=north,1=east,2=south,J5=west 


long ticks_ per_trame; // Number of clock ticks per 
‘* frame of animation 


void maintvoid) 

{ 
event _struct events; 
struct xy newpos; 


‘/ Create pointer to video memory: 
char far *“screen=(char far *)MK_FP(OxaQ000,0); 


f/f Create offscreen video buffer: 
char far “screen_buffer=new unsigned char [64000]; 
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if Load compass picture: 
if (lLoadPCxX("compass.pecx",&compasses)) exit(1); 


// Load compass faces into array: 
for (int num=0; num<4; num++) ¢ 
compass faceCnuml=onew unsigned char(l42*41); 
grabli/+num*50,18,462,41,3520, compasses. image,compass_faceLnum]); 
} 


ff Dispose of compass picture: 
delete compasses. image; 


ff Load background image: 
i¢# (lLoadTGAC"empty.tga",&bglOI)) exit(1); 
if ClLoadTGAC"empty.tga",&bgl1])) exit(1); 


ff Load wall bitmap: 
if C(loadTGAt"front)].tga",Swall)) exited); 


f/f AllLot memory for wall bitmap: 
tpoly. textmap=new charl95*/9] > 


f? Grab wall image in array: 
grabt4/,20,96,/79,188,wall. image, tpoly. textmap) ; 


ff Initialize event manager: 
init_events(); 


// Calibrate the user's joystick: 

if C(WHICH_EVENTS & JOTSTICK_EVENTS) f 
printt(’\nCenter your joystick and press button "); 
printt("one.\n"); 
setcenter(); // Calibrate the center position 
printt( "Move your joystick to the upper lefthand “}; 
printft("corner and press button one.\n"); 
setmint}; ff Calibrate the minimum position 
printt("Move your joystick to the Lower righthand ")>; 
printf<"corner and press button one. \n"); 
setmax(); ff Calibrate the maximum position 


} 


ff Save previous video mode: 
int oldmode=*Cint *)MK_FP(Ox40,0%49): 


ff Put display in mode 13h: 
setmode(Ox13); 


‘/ Set palette to PCX palette: 
setpalette<bglO].color_map); 


‘if Clear display: 
cle(screen_buffer); 
Cer fined OP AEN Did Pe 
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ticks per_frame = CLK_TCK / FRAMES PER SECOND; 


ff Initialize the frame timer: 
clock_t lastframe=clock()> 


// Make sure we get at least one frame 
f/f into the maze: 
events.quit_game=0; 


/f Put initial image of maze in screen buffer: 
drawbg(0,screen_buffer); 
drawmaze(0,0,0,WWIDTH=1,screen_buffer): 


ff Point to first bg buffer: 
int bonum=0; 


// Let's go for a walk in the maze: 
while(leyents.quit_game) ¢ 


// Draw the maze in screen buffer: 

clrwin( XWINDOW, TWINDOW,WWIDTH,WHEIGHT,screen_buffer); 
drawbg(bgnum,screen_butfer}; 
drawmaze(0,0,0,WWIBTH-1,screen_butfer}; 


// Move screen buffer to screen: 
putwindowt XWINDOW, YWINDOW,WWIDTH,WHEIGHT,screen_ buffer}; 


/*f Put compass next to maze window: 
blit(20,55,42,41,screen,compass faceldir]); 


ff Pause until time for next frame: 
while (C€clock()-Lastframe)<ticks_ per_frame) ; 


‘f/f Start timing another frame: 
Lastframe=clock(); 


‘/ Move viewer according to input events: 
getevent (WHICH_EVENTS,&events); 


/* Do we want to move forward? 
if Cevents.go_forward) tf 
newpos.x=pos.x+forward(dird.x; 
newpos.y=pos.y+forward(dirl].y; 
1f ('mazelLnewpos.xlJlnewpos.y¥J) ¢ 
pos. X=newpos.x: 
pos. y=newpos.y; 
} 
} 


f/f ...0r do we want to move backward? 
else if (events.go_back) f 
newpos.x=pos.x—-forward(dir].«; 
newpos.y=pos.¥-forwardldirl.y; 
if (!mazelnewpos.xJCnewpos.yJ) { 





} 
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pos. x=newpos.x; 
pos. y=newpos.y; 
} 
} 


ff Do we want to turn Lett? 
if (events.go_left) f 
—=dir.: 
if (dirs) dir=3; 
Eg riuim++ ; 
if (bgnum>1) bonum=0; 
} 


f/ ...or do we want to turn right? 
else if Cevents.go_right) f 
dirt++; 
if (dire3) dir=0; 
bgnum——; 
if {bgnum<0) bgnum=1; 
} 
} 


‘/ Terminate event manager: 
end_events(); 


/f Release memory 
delete tpoly.textmap; 
delete wall.image; 
delete wall.color_map; 
if (wall.ID) delete wall.Ib; 
for Cint 17-0; 1i<2; iit+) f 
delete Bgliil. image; 
delete bgliil.color_map; 
if (boliij].1B) delete bgliiJj.1IB; 
} 


for (int jj=0; 73<4; delete compass_faceLljj++J]); 
delete screen_butfer; 


‘f/f Restore old video mode: 
setmodeloldmode) ; 


void drawbgtint num,char far *sereen) 


{ 


unsigned int offsetl=YWINDOW*320+XWINDOW: 
unsigned int offset2=0; 
for Cint 1=0; i<WHEIGHT; i++) f 
for Cint j=0; j<WWIDTH; j++) 
screenLoffsett++J=bglnum]. imageloffsete++]; 
offseti+=(320-WWIDTH); 
} 
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vold drawmazelint wshift,int yshift,int Lview,int rview,char *screen) 


// Recursive function to draw left, right and center walls for the 

‘fo maze square at POS. M4+XSHIFT, POS. Y+VYSHIFT, as viewed from POS.X, 
/f POS.Y, within the screen window bordered by horizontal coordinates 
/f LVIEW and RVIEW on the Left and right respectively. When called 

ff with XSHIFT and YSHIFT set to 0, draws entire maze as viewed 

// from POS.E,POS.¥ out to VIEW_LIMIT squares. 


int vleft,vright,vwidth; 


ff Return if we've reached the recursive Limit: 
if (Cabs(xshift) > VIEW LIMIT) || Cabs(yshift) > VIEW LIMIT)) 
return; 


/f Calculate coordinates of square to Left: 
int sx = pos.x + (xshift+l) * leftCdirl.x + yshift * forward[dird.x; 
int sy = pos.y + (xshift+l) * Llettldiri.y * yshitt * forwardldird.y; 


ff Get left-right extent of Left part of view: 
vleft=Lview; 
veight=matrixLyshift+) ILxshi ft+VIEW LIMIT+1I; 
if (vright>=rview) vright=rview; 
wwidth=vright-vleft; 


if (vwidth>0) ¢ 


‘/ If the square to the left is occupied, 
f/f draw right side of cube: 
if (mazeCsxICsyl]) { 


tpoly.xlOJ=matrixCyshiftilxshi ft+VIEW LIMIT+1 J+XWINDOW; 

tpoly.yCOJ=toplyshiftJ+yYWwINdow; 

tpoly.xCil=matrixlyshitt+) I0xshi ft+VIEW _LIMIT+1 J+XWINDOW; 

tpoly.yliJ=toplyshi ft+1 J+ YWINDow; 

tpoly.yl2J=bottomlyshitt+l J+7¥WIhbOw : 

tpoly.yC3J=bottomlyshitt]+¥WINDOW; 

tpoly.wtext=95; 

tpoly. htext="9; 

polytext(Etpoly,vleft+eWINDOW, YWINDOW, vright+XWINDOW, 
Y¥WINDOW+WHEIGHT,screen); 

} 


‘i Else call function recursively to draw the view from 
// next square to the Left: 
else drawmaze(xshift+l,yshift,vleft,vright,screen) ; 


} 


‘i Calculate coordinates of square directly ahead: 
sx = pos.x + xshift * LeftLdirl.« + (yshiftt+l) * forwardLdird.x; 
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sy = pos.y + xshift * leftldir].y + (Cyshift+]) * forwardl[dird.y; 


ff Get Left=right extent of center part of view: 
vleft=omatrixCyshift+l Jixshift+VIEW_LIMIT+1]; 
vright=matrixCyshift4+TIOxshift+vVIEw_LIMITJ; 

if (vleft<lview) vleft=lview; 

if (vright*rview) vright=rview; 
vetdth=vright-vleft; 


if (vwidth>0) f{ 


‘/ Tf the square directly ahead is occupied, 

ff draw front of cube: 

if (maze[sxJ0sy]) f 
tpoly.«xCOJ=matrixlyshift+1ICxshi ft+VIEW_LIMIT+114+xWINDOW; 
tpoly.ylOJ=toplyshitt+1J+1WINDow; 
tooly.xCiJ=matrixCyshitft+1IJ0xshift+VIEW LIMITI+¥WINDOW ; 
tooly.¥0l1J=toplyshi ft+1J+v¥WwINDow; 
tpoly.yl2J=bottomEyshift+1J+YWINDOW: 
tpoly.y0l3lJ=bottomlyshif t+] J+YWwINDOw; 
tpoly.wtext=95; 
tpoly. htext=79; 
polytext(&tpoly,vleft+XWINDOW, YWINDOW, vright+XWINDOw, 

YWINDOW+WHEIGHT,screen) ; 
I 


ff Else call function recursively to draw the view from 
‘/ next square forward: 
else drawmaze(xshift,yshift+l,vleft,wright,screen); 

} 


‘/ Calculate coordinates of square to right: 
sx = pos.x + (xshift-1) * LeftCdir].x + yshift * forward[dirl.x; 
sy = pos.y + (xshift-1) * Leftldiri.y + yshift * forwardldirl.y¥; 


ff Get Left-right extent of right part of view: 
vVlett=matrixLyshittt] ILxshi ft+ViIEW_LIAITI; 

if (wleft<lview) vleft=lview; 

vright=rview: 

vwidth=vright-vLleft; 


if (wwidth>0) f 


‘f If the square to the right is occupied, 

‘/ draw Left side of cube: 

if (mazeCsxJ[syl]) f 
tpoly.xCOJ=matrixCyshift+lICxshift+VIEW_LIMITJ+XWINDOW; 
tpoly.¥lOJ=toplyshift+) J+¥WINDOW; 
tpoly.xCll=matrixCyshiftiCxshi ft+VIEW_LIMITI+XWINDOW: 
tpoly.¥Cll=toplyshift]+yWINDOW; 
tpoly. yCl2J=bottomLyshi ftJ+¥WINDOow ; 
tpoly.yCSJ=bottomEyshift+1J+iwINbow ; 
tpoly.wtext=95; 
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commie from premione purge 
tpoly.htext=79; 
polytext(&tpoly,vleft+XWINDOW, WINDOW, vright+XWINDOW, 
YWINDOW+WHEIGHT, screen); 
} 


// Else call function recursively to draw the view from 
// next square to the right: 
else drawmaze(xshift-1,yshift,vleft,vright,screen) ; 


Running the Program 

To run TEATMAZE.CPR, go to the TEXTURE directory and type TEXT MAZE. 
As in our earlier maze animations, you can guide yourself through the maze by 
pressing the arty keys OF Moy Ing the MOUSE. 

Youll notice that while the graphics in TEXTMAZE are certainly superior to 
the graphics in the POLYMAZE program, they are still somewhat less vivid than 
those in the BITMA#E program. In a sense, thats the price we pay for greatly 
reducing the amount of memory storage necessary to hold the bitmaps; 
TEXTMAZE will run in a fraction of the RAM required by BITMAZE, which 
means that we could greatly expand the number of bitmaps used, including 
bitmaps for doors, windows, other types of walls, and so forth. 

And there are a number of ways in which TEXTMAZE could be improved. 
For instance, we could add lightsourcing to give a sense of depth to the walls. 
Walls at a distance from us could be drawn in a darker color than nearby walls, 
adding an extra sense of depth. And walls tilted at an angle to the viewer could be 
hiled with gradient colors growing darker along the 2 axis of the wall. Well talk 
more about lightsourcing in a later chapter, and suggest ways in which it could be 
added to this program. 


Going Three-Dimensional 

Perhaps the greatest improvement that could be made to TEXTMA/ZE, though, 
would be to turn it into a full three-dimensional game. One of the advantages of 
drawing polygons on the fly is that we can place the vertices of those polygons any 
place on the screen that we wish to; we are no longer enslaved by our predesigned 
bitmaps. By applying mathematical operations to the geometry of the dungeon, 
we can make the walls move as smoothly and realistically as we wish, 

In the next chapter, well talk abour the mathematical basis for 3D graphics. 
Then, in the chapters that follow, we'll introduce a new technique for generating 
three-dimensional dungeons that will take advantage of the techniques in the 
next chapter and more. 
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t probably doesnt come as earthshaking news to you that the 
video display of an IBM-compatible microcomputer is flat, Well, 
okay, it may be curved slightly at the edges on some models, but 
this minor physical quirk has no effect on the way in which 
—-4 eraphics are programmed. We must still place pixels on the 
screen as if we were laying them side by side on a plane, 

In mathematics a plane is an abstraction, a theoretical entity with two 
dimensions, which we can reter to as the horizontal and vertical dimensions, or 





simply as width and height. These two dimensions correspond to the two axes of 
a Cartesian plane, with width corresponding to the x axis and height 
corresponding to the y axis. Once again, this probably doesnt come as a late- 
breaking news item, since weve been using the x and y axes of the Cartesian 
plane to correspond to the width and height of the graphic images in the earlier 
chapters of this book. 

And, tn fact, this has presented something of a minor programming problem, 
since the image on a video display is represented by a sequence of numbers in 
the computers memory that is essentially one dimensional. Why would we regard 
a computers memory as one dimensional? Because it is a kind of line, which 
extends from the first address in memory to the last. This line has only a single 
dimension, which we can think of as a kind of length. A computer with 8 
megabytes of internal memory, for instance, can be thought of as having a 
memory that is 8,388,608 bytes long, (A megabyte, as you're probably aware, is 
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Figure 7-1 4 line measured at Figure 7-2 The crisscrossed axes of a 


comsistent intervals with numbered Caresian-plane can be thought of as 2 pair 
Increments is called.a nurnber line of horizontal and vertical number lines 


equal to 1,024 kilobytes, which are in turn equal to 1,024 bytes apiece. Thus a 
megabyte is 1024 x 1024, or 1,048,576, bytes.) 

In math the concept of a line measured at consistent intervals with numbered 
increments is called a mwmber lime, You can see a picture of one in Figure 7-1, 
The memory of a microcomputer can be thought of as a kind of number line. So 
can the x and y axes of a Cartesian plane, as in Figure 7-2. The difference 
berveen a single number line like the computers memory and the crisscrossed 
axes of a Cartesian plane is that the single number line defines only a single 
dimension — the length of the line itself — while the ewo number lines of the 
axes define a two-dimensional area that extends beyond the axes themselves to 
encompass the entire plane in which they lie. 

The magic of even the simplest computer graphics is that we are making a 
one-dimensional number line (the memory of the computer) represent a two- 
dimensional plane (the Hat video display of the computer). We can only get away 
with this because the width of the computer display is finite. If it were infinite, 
going on forever the way that a plane in geometry does, we couldn't pull this 
trick off. Burt the fact that the display is only 320 pixels wide (in mode 13h) 
allows us to use sequential chunks of our one-dimensional memory to simulate 
both the horizontal and vertical dimensions of space. Each 320-byte chunk of 
memory simulates 320 pixels worth of horizontal space while a sequence of these 
chunks lined up one after another in video memory simulates the vertical 
dimension of space. Moving horizontally across this plane, or the 320-prtxel 
section of it we are allowed to work with, is a simple matter of moving forward 
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and backward byte by byte through memory. Moving vertically is a slightly more 
complicated matter of moving forward and backward 320 bytes at a time 
through memory. Although in both cases we are moving along the same 
dimension of our computer's memory (since, after all, our computers memory 
only Aas a single dimension), this trick of arranging memory in 32()-byte chunks 
allows us to simulate movement in the two dimensions of the video display. The 
VGA adapter then completes the illusion by translating our one-dimensional 
movement through memory into rea! two-dimensional movement on the video 


display. 


The Third Dimension 


Until now, we've restricted ourselves to performing this relatively simple trick: 
translating the one dimension of video memory into the two dimensions of the 
video display. More and More, however, COMPUtEr Relies te moving beyond the 
simple two-dimensional graphic effects that the video display of a microcomputer 
is intended to provide and into something much more complicated: the third 
dimension, One of the most popular categories of game software — for that 
matter, one of the most popular categories of software — is the Hight simulator, 
The Microsoft Flight Simulator, which was up to Version 5 at the time this book 
was written, is one of the ten most popular general software titles of all time, 

Flight simulators, which (as you might guess from the name) simulate the 
experience of flying in an airplane or other type of aircraft, use the two 
dimensions of the video display to represent something even more complex: the 
three dimensions of space. 

To James Tiberius Kirk, space is the final frontier, but to a mathematician it is 
the three-dimensional equivalent of a plane, an abstract entity that has three 
dimensions. These dimensions are sometimes referred to as length, width, and 
breadth. Which of these corresponds to the height dimension that we referred to 
when we were talking about nvo-dimensional planes? It really doesnt matter. [t 
could be any of these dimensions. Although when speaking of ovo-dimensional 
planes, we tend to refer to the up-and-down dimension as height and the right- 
and-left dimension as width, these orientations are merely incidental artifacts of 
the gravitational feld in which we live. If you turned your computer display on 
its side (and didnt knock the picture tube loose in the process), youd neatly 
switch width for height and vice versa, though the program that you were 
running would never know youd done so. 

A dimension is simply a way in which a line can be at right angles to another 
line. We refer to a plane as two-dimensional because we can have at most two 
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Figure 7-3 Ona two-dimensional plane, Figure 7-4 In thrée-dimensional space, 
We can Nave at most two lines at night we could have at most three lines at 
angles to ane another right angles to one another 


lines at right angles ro one another, as demonstrated in Figure 7-3. If we could 
draw lines in space, we could have up co three lines simultaneously at right angles 
co one another, as in Figure 7-4, 


Three-Dimensional Cartesian Space 

The easiest way to deal with dimensions mathematically — or even 
nonmathematically, if you want to cur through all of the confusion about which 
dimension goes up and down and which dimension goes right and left and so 
forth — is to think of them in terms of Cartesian axes. The Cartesian plane is 
called a plane because it has pwo axes and therefore nwo dimensions. It follows, 
then, that if we added a third dimension we could transform our two- 
dimensional Cartesian plane into a three-dimensional Cartesian space. 

And, in fact, we can, as shown in Figure 7-5. Just as the rwo axes of the 
traditional Cartesian plane — the x and y axes — run perpendicular to one 
another, so the third axis of Cartesian space runs perpendicular to both of these 
axes. Naturally enough, we refer to it as the z axis. (The fact that mathematicians 
have chosen to use the letters so near the end of the alphabet to designate the 
Cartesian axes doesnt leave much room for us to give a name to a fourth axis, 
should we decide to create a graph for a four-dimensional Cartesian hyperspace. 
Fortunately, we wont have to do that in this book — and most of us will never 
have to do it in our lives.) 
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Figure 7-5 By adding a third axis, we can Figure 7-6 The point is at coordinate 3. 
Create a three-cimensional equivalent of -5. 2, relative to the three aves of this 
a Cartesian plane Cartesian space 


Just as any point on a Cartesian plane can be designated by two coordinates 
representing its position relative to a pair of x,y axes, so any point in Cartesian 
space can be designated by three coordinates representing its position relative to a 
trio of x, y, and z axes. For instance, the levitating point in Figure 7-6 is aligned 
with the x, y, and z axes in the illustration at positions equivalent to the 3 on the 
x axis, the -5 position on the y axis, and the 2 on the z axis. Thus we can identify 
this point as being at position 3,-5,2 in Cartesian space — or, at least, in the 
particular Cartesian space represented by this picture. If we moved our axes to 
different positions in space without moving this point, the coordinates of the 
paint would change. So when we say that this point has the coordinates 3,-5,2, 
we are actually saying it has those coordinates relative to the origin of this 
particular Cartesian system. As in a two-dimensional Cartesian coordinate 
system, the origin of a three-dimensional coordinate system ts the point where all 
three axes come together at position 0. 


The Three-Dimensional Illusion 


So tar, weve treated the video display of the computer as equivalent to a two- 
dimensional Cartesian plane, with the x axis running horizontally across the top 
of the display and the y axis running vertically down the left side. Is it possible 
also to treat the display as a three-dimensional Cartesian space? Yes and no. As 
weve noted, the display is essentially Hat, so we done really have a third 
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dimension to deal with. But weve already worked out a trick that translates the 
one-dimensional memory of the microcomputer’s video memory into the two 
dimensions of the video display. So we should be able to use similar, tf 
considerably more complex, trickery to translate the two dimensions of the video 
display into the illusion of a three-dimensional world. 

This is exactly what almost every Hight simularor on the market does. Pick up 
a copy of the Microsoft Flight Simulator or Spectrum Holobyte’s Falcon 3.0 or 
Origin Systems Strike Commander, and you'll see a three-dimensional world 
stretching away from you out the window of the aircraft simulated by the 
program. OF course, this world isn't really three-dimensional. It’s actually a 
collection of pixels on a flat video display. But the fight simulator program 
produces the illusion chat the world outside the window is three-dimensional, 
just as the masterly painters of the Renaissance produced the illusion of a third 
dimension in the dramatic lines of perspective that they were so fond of adding 
to their paintings. 

There's no real third dimension in these images because there's no optic 
parallax, the effect that occurs when each of your pvo eyes sees the world from a 
slightly different angle. Uhis effect caw be achieved on a computer video display 
through the use of certain kinds of 3D glasses, such as the ones with the red and 
blue lenses, but most people arent fond of donning special goggles every time 
they sit down to play a computer game. And besides, the three-dimensional 
illusion produced by a flight simulator is every bit as good as the three- 
dimensional illusion produced by a television show or a motion picture, both of 
which are depicted on Hat screens. Not many people complain that television 
pictures look flat. 

Why noc Why arent we frustrated by the nwo-dimensionaliry of television, 
motion picture, and Hight stimulator images? Because optic parallax isn't all that 
there is to three-dimenstonal vision. In fact, it's just a small part of three- 
dimensional vision, an evolutionary trick picked up by our distant, tree-dwelling 
ancestors that made it a little less likely that they would misjudge the distance to 
a branch and go crashing ignominiously (and possibly fatally) to the ground, 


Putting Perspective in Perspective 


What really gives an image the look of three-dimensionality is perspective, the 
way in which objects appear to grow smaller and larger as their distance from the 
viewer increases and decreases, respectively. This is the result of the way in which 
rays of light reflected from (or produced by) those objects converge on our eyes. 
Well talk abour this at considerably greater length tn later chapters, because tt ts 
the key to some of our most vivid and realistic maze creation programs. For now, 
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Apples 


Figure 7-7? [his apple appears to grow smaller the farther away from us itis 


however, we can regard perspective as a simple increase or decrease in the 
apparent visual size of an object with distance, as in Figure 7-7 

Actually, we can be a little more specific than that. Perspective is the way in 
which points in our visual held tend to converge on the origin of our visual 
systems with distance. How's that again? Imagine that the Geld of view that you 
can see with your eyes is a kind of two-dimensional Cartesian viewing plane, 
ignoring for a moment the third dimension. Imagine further that at the center of 
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Figure 7-8 Imagine that your visual field 
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Figure 7-9 This point is the same as the Figure 7-10 This paint is the sameé as 
one in Figure /-10, Dut viewed froma the one in Figure 7-9, but wewed from a 
greater astance closer distance 


this viewing plane is the origin of a pair of x,y Cartesian axes (see Figure 7-8). 
Now go stand in a large open held and position yourself so that some small 
object — we'll imagine that this is a point in Cartesian space — is slightly off 
center in your visual held. Walk toward the center of your visual held (not toward 
the object) and then back away from it again. Notice that the object appears to 
move farther away from the center of your visual held as you move forward, and 
closer to the center of your visual held as you move away from it. 

We can simulate this on a two-dimensional Cartesian graph by putting the 
origin in the center of the graph and moving a point closer to and further away 
from that origin to make it appear that the point is getting closer to us, then 
further away from us. For instance, we can imagine that the point on the graph 
in Figure 7-9 is the same point as the one on the graph in Figure 7-10, viewed 
from a greater distance. How do we know that it is viewed from a greater 
distance in Figure 7-9? Because it is closer to the origin. 

We can imagine that the video display of a microcomputer has a z axis that 
runs into and out of the screen, as shown in Figure 7-11. For now, we'll regard 
this axis as being positive going into the display — that is, the numbers on the 
axis go up as we move forward into the display and go down as we move 
backward toward the viewer. If the origin of the z axis is right on the display 
itself, the negative points on the axis will be on the same side of the display as the 
viewer and the positive values will be on the opposite side. 

This allows us to treat the display as a three-dimensional Cartesian space, at 
least in our imaginations. To get this three-dimensional information out of our 
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Figure 7-11 We can imagine that the video display of a 
microcamputer has az axis Chat runs into and out oF the 
screen 


imaginations and into our programs, we can develop a simple pair of equations 
for adding perspective information to the position of a point on a Cartesian 
graph: 
MX persp =x / z 
y¥_persp = y fz 
where the x, » and z variables represent the x, y, and z coordinates of the point in 
Cartesian space and the x_persp and y_persp variables represent the perspective- 
adjusted projections of these points onto a two-dimensional Cartesian plane — 
such as a video display. How do these equations work? Basically, they add 2 axis 
information to the x and y axis information on the screen, Dividing the 
z axis value into the x and y axis values causes the x and y axis values to become 
smaller as the z value becomes larger, just as they appear to in your visual held. 
Actually, the equations given above cause the x and y axis values to become 
smaller a bit too quickly for most 3D graphics systems. We need a way to slow 
down the process a bit, so chat the points dont converge immediately on the 
origin as they move away from us along the imaginary z axis. One way is to 
multiply the x and y values by a constant, like this: 


x screen = viewer_distance * x space / z space; 
y_screen = viewer_distance*® y_space / z_space; 
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where x_space, y_space, and 2z_space are the three-dimensional Cartesian 
coordinates of the point in space; x_screen and y_sereen are the pwo-dimensional 
Cartesian coordinates at which the point would be drawn on the screen; and 
VIEWER_DISTANCE is a constant value used to fine-tune the rapidiry with 
which objects tend to recede into the distance. Generally, values berween about 
100 and 1,000 tend to work well for this constant. 

You can think of the VIEWER_DISTANCE constant as representing the 
distance from the viewers eyes to the video display, measured in pixels. (There 
arent any pixels in the space between the viewer and the display, of course, but 
we can measure this space using units approximately equivalent to the size of 
pixels on the display.) If we imagine that the display is a window into a genuine 
three-dimensional world, then moving the viewer closer to the display would 
allow him or her to see a wider angle view of that world. Moving further away 
from the display would create a narrower angle of view. And this is precisely the 
effect that we get when we increase or decrease the VIEWER_DISTANCE 
constant, However, since we cant expand or shrink the display itself along with 
the VIEWER DISTANCE constant, the actual result is that more visual data Is 
crammed into the width of the viewport when the value of the constant is low 
and less data is crammed into the viewport when the value is high. 


Two-and-a-Half Dimensions? 


This is one of the tricks that fight simulators use to give the illusion of a three- 
dimensional world on the video display of a microcomputer. (We'll talk about 
some more of these tricks in a moment.) Most flight simulators use a graphics 
system known as polygon-hll graphics, in which objects in space are represented 
as a series of Hat shapes with straight sides. In math a Hat shape constructed from 
a series of straight sides, like the one in Figure 7-12, is called a polygon. A 
polygon depicted on the computer display with its interior filled by a solid color 
is called a filled polygon. Thus, polygon-fll graphics systems build up a three- 
dimensional “world” out of filled polygons. 

The only information needed to describe a polygon in Cartesian space are the 
coordinates of the points at which the straight lines that make up the “sides” of 
the polygons come together. These points are called vertices, and can be 
represented like any other points in space — by a trio of Cartesian coordinates. A 
polygon floating in space can be represented in a computer program such as a 
Hight simulator as a list of coordinates, going clockwise or counterclockwise 
around the polygon, And this is what a lot of fight simulators do. 
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Figure 7-12 A flat shape constructed 
from a series of straight sides is called a 
polygon 


Once you have a polygon represented in this form, it can be “projected” onto 
the display using the perspective equations that we discussed earlier, or some 
variation thereon. [hart is, the three-dimensional coordinates of the vertices 
within the “world” of the flight stmulator — which ts actually just a segment of 
Cartesian space, the way that the computer screen is a segment of a Cartesian 
plane — can be converted into two-dimensional screen coordinates by dividing 
the x and y coordinates (after multiplication by a constant) by the z coordinates. 
The polygon that connects those points on the display can then be drawn. 

This is a straightforward programming problem and much of my book Fighes 
af Fantasy is concerned with solving it. Most flight simulators solve it in one way 
or another, and some of the more recent ones have come up with very 
sophisticated solutions indeed. For instance, some Hight simulators now employ 
polygon-smoothing techniques that give the ordinarily Hat polygons a smooth, 
curved look, or texture-mapping techniques that fill the polygons with complete 
bitmaps rather than just solid colors. (We talked about simple forms of texture 
mapping in chapter 6.) 

Is this what we ll have to do in order to bring a convincing three- 
dimensionality to our maze programs? Will we need to represent our maze as a 
series of fully three-dimensional polygons and perform all of the operations on 
these polygons that a flight simulator does, including edge clipping, hidden 
surface removal, and perspective projection? Not necessarily. Although we could 
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create a maze program in precisely this manner — the Ultima Underworld games 
from Origin, for instance, seem to go some distance in this direction — it isn't 
easy to use Hight simulator techniques to represent a maze. For one thing, there 
are often a lot more polygons involved in building a maze than in building the 
sort of polygon world that most flight simulator craft fly around in, And the 
player can get a lot closer to those polygons in a maze than an airplane usually 
does to ground scenery, which demands greater realism in the special effects of a 
maze program than the typical Hight simulator provides (though the realism 
quotient of some recent Hight simulators has increased amazingly). 

Fortunately, we dont have to go a full three dimensions in order to make our 
maze program seem three-dimensional. [hats because a maze is essentially a two- 
dimensional object. The mazes that we've created in earlier chapters, for instance, 
were represented by two-dimensional arrays, because there really wasnt any third- 
dimensional information that we needed to know about in order to draw them. 
Although the mazes that we drew /ooked three-dimensional, the third dimension 
— which we can think of as the height of the maze blocks above the ground — 
wasnt really there. Why? Because all of the maze blocks were the same height. 
Thus information about the height of individual blocks — or anything else — 
didnt need to be stored in the array. 

Indeed, if you look at most maze games on the market (the Ultima 
Underworld games once again excepted), you'll see that there is relatively little 
height information in them. In Wolfenstein 3D, for instance, all of the walls are 
the same height. The Wolf 3D maze is essentially two-dimensional. Yet we get 
the illusion that we are moving through it in three dimensions. You might say 
that the mazes in most games are actually teo-and-a-balPatmenstonal. 

In this book, although [ll make a nod toward full three-dimensional maze 
creation, we'll talk mostly about two-and-a-half-dimensional mazes, Why? 
Because rwo-and-a-half-dimensional maze-generation systems are the best 
methods currently available for generating high-speed maze games. Later, in the 
chapter on heightmapping, well talk about ways of crunching genuine three- 
dimensional height information into our two-and-a-hall-dimensional mazes, but 
for the most part well fake the third dimension. This will allow us to produce 
high-speed animation, which in turn will let us place our programming resources 
where they really belong: on creating as realistic appearing an environment as 
possible. Dont worry; the player will never know that the third dimension really 
isnt there. 

Nonetheless, we'll also be discussing the theory of fully three-dimensional 
programming, because we'll be needing it in later chapters to give the illusion 
that there is a third dimension present in the maze worlds we create. And the first 
of these three-dimensional concepts that we'll need to discuss — one that applies 
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equally well to programming in two-dimensional environments — Is the concept 
of a direction vector. 


Direction Vectors 


A Cartesian coordinate system is a terrihe way of designating the position of a 
point, either on a plane or in three-dimensional space (or in any number of 
dimensions, if you should have need of them). It can also be used to create other 
rypes of shapes, such as lines. In fact, we did just this in chapters 2 and 3, where 
we drew lines berween points on screens using Bresenhams algorithm, 

In that case we described the lines by giving the coordinates of their 
endpoints, like this: 


x_start,y_start - x_end,y_end 


where x_start,y_start are the coordinates of the end of the point where we began 
drawing the line and x_end,y_end are the coordinates of the point where we 
stopped, Indeed, this ts all the information that we need to completely describe a 
line in terms of the Cartesian plane on which the line lies. If we need to, we can 
similarly describe a line in three-dimensional space by using three coordinates for 
each endpoint, like this: 

x start,y_start,z_start - x_end,y_end,z_end 


There is, however, another method that can be used to describe a line in 
Cartesian coordinates, one that will often be more useful for our purposes than 
this. That method ts to describe the line Using Its direction vector and 
magnitude. 

The magnitude of a line is simply its length, in terms of the same unit of 
measurement used along the x and y axes of the coordinate system. (Since these 
units can correspond to any real-world units that we want them to — miles, 
fathoms, light-years — we'll refer to them as Cartesian units or just as units.) A 
direction vector is something slightly more complicated. 

In mathematics the term vector is sometimes used to describe any one- 
dimensional array of numbers. For instance, the coordinate pair used to describe 
the position of a point on a two-dimensional plane (or the coordinate triple used 
to describe the position of a point in three-dimensional space) can be called a 
vector, However, the term vector is interchangeably (and sometimes confusingly) 
applied to a special pair (or trio) of numbers thar can be used to desertbe the 
direction of a line in a Cartesian coordinate system, Well refer to such a pair (or 
trio) of numbers in this book as a direction vector. 


GARDENS OF IMAGINATION 





— Ww me on oe 4 a 8 = 





| 
] 
0 
1 
i! F 
H E 
- | 


Figure 7-13 A line from coordinates 7.4 
to 8.6 


In a two-dimensional Cartesian coordinate system, a direction vector is a pair 
of numbers that tell us how much the x and y coordinates of a line change from 
the starting point of a line to the ending point — or, for that matter, between 
any two arbitrary points on the line. The first number, which represents the 
change in the x coordinate, is called the x component of the vector and the 
second number, which represents the change in the y coordinate, is called the y 
component of the vector. A direction vector looks an awful lot like a coordinate 
pair. And, in fact, we can translate easily between direction vectors and 
coordinate pairs. For instance, the direction vector for a line can be easily derived 
from its starting points and ending points, by subtracting the starting x point 
from the ending x point and the starting y point from the ending y point, like 
this: 
x_vector = x_start — x_end; 
¥ vector = y_start — y_end; 
where X_shart,y_start are the components of the start of the line, x_end,y_end are 
the components of the end of the line, and x_vector,y_vector are the x and y 
components of the direction vector for the line, Does it matter which end of the 
line we start at and which end we end at? Theoretically, it does, since the x and y 
components of a direction vector that runs in one direction will have the 
opposite signs from a direction vector running in the opposite direction. For 
many practical purposes, though, we can ignore this. For instance, in drawing a 
line on the screen, it doesnt matter which end we finish drawing ar, since the 
user doesnt usually see it being drawn. For other purposes, it will matter. In most 
cases, however, it will be obvious which end of the line is which. 
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Figure 7-14 Measuring the direction 
vector over half the line t equivalent to 
measuring it over the entire line 


For example, the line in Figure 7-13 runs from coordinates 2,4 to coordinates 
8,6. If we treat the 2,4 end as the starting point and the 8,6 end as the ending 
point, the direction vector for this line would be 6,2, where 6 is 8 minus 2 and 2 
is G minus 4. If we chose to reverse the ends of the line, starting at the 8,6 end 
and ending at the 2,4 end, it would reverse the vector as well to -6,-2. 

A direction vector is essentially a ratio, showing the relationship between the 
changes in the x and y values along the length of the line. So the numbers 
themselves dont matter as much Fs) the relationship between them. We can 
change the numbers in the vector without changing the direction that the vector 
represents, as long as we dont change the ratio between the numbers. Thus we 
can multiply both components of the vector by the same number or divide both 
components of the vector by the same number without fundamentally changing 
it, since this leaves the ratio between the numbers 1 Intact, For 1 IMs Tahhce, the yector 
6,2 of the line in Figure 7-13 can also be expressed as 12,4 (where both 
components have been multiplied by 2) and as 3,1 (where both components have 
been divided by 2). 

This means that we can obtain the direction vector by measuring the change 
in the x,y coordinates along any segment of the line, as well as along the entire 
length (or magnitude) of the line. For instance, in Figure 7-14 we obtain the 
direction vector of the line from Figure 7-13 by measuring the change in the x,y 
coordinates from the starting point at 2,4 to the midpoint at 5,5. The direction 
vector that we get in doing so is 3,1, which we just saw in the last paragraph 1s 
equivalent to the direction vector 6,2 that we got from measuring the change in 
the x,y coordinates along the entire length of line. (In fact, it is the direction 





QARDENS OF IMAGINATION 


vector that we got by dividing the 6,2 vector by the constant 2, not surprising 
considering that it represents the change in x and y along half the line.) 


Vector Magnitude 


Since a direction vector is a ratio rather than a pair of absolute lengths, it does 
not give us a length for the line the vector is describing. And, in fact, we dont 
always need to know the length of such a line. In many cases, as we'll see in later 
chapters, the direction of the line is all we need to know, (In some specific cases, 
such as the so-called normal vector that describes the orientation of a plane in 
space, the line described by the vector is indefinitely long, so talking about its 
length is meaningless, More about normal vectors in chapter 8.) 

Nonetheless, there will obviously be times when we need to know the length 
of a line as well as its direction vector. (In fact, there will be times when the 
length of a line is the information that we really need and the direction vector for 
the line can be ignored altogether. This is frequently the case when we need to 
know the distance to a point in space in order to make perspective calculations.) 
Thus we need to calculate the length of a line in Cartesian units based on the 
coordinates of its endpoints. In some cases this will be a trivial matter, especially 
in the case of lines that are parallel to one of the Cartesian axes. In Figure 7-15, 
for instance, the line runs parallel to the x axis from coordinates 1,3 to 
coordinates 7,3 so we can easily calculate that this line is 6 units long. 

But what about the line in Figure 7-16, which runs from starting coordinates 
3,2 to ending coordinates 5,7? Whar ts the length of this line? There are a couple 
of different ways in which we can calculate it. For the time being, we'll fall back 


i 
L 


aay 
edi fice 
4 
Li 
het 
i: 
je 
ee 
me 
ae 
4 


LB EEE Eile 





Figure 7-15 A line running parallel to the x Figure 7-16 4 line from coordinates 4,2 
axis fram coordinates 1,3 to coordinates 7,3 to coordinates 5,7 
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(3x3)+(4x4)=(5x 5) 


Figure 7-17 Yes, the square of the hypotenuse really is equal to the sum of the squares of 
the other two sides 


on the familiar Pythagorean theorem, which states that the square of the 
hypotenuse of a right triangle is equal to the sums of the squares of the other two 
sides. In Figure 7-17, for instance, we see a right triangle in which — by golly — 
Pythagoras theorem turns out to be true! 

Although you may have suspected that youd never need this theorem again 
after graduating from school, it comes in quite handy for calculating the length 
of a line within a Cartesian system, since it turns our that any line in a Cartesian 
coordinate system Can be treated aS the hypotenuse of cl right triangle and the 
changes in the x and y coordinates berpween one end of this line and the next can 
be treated as the other rwo sides (see Figure 7-18). 

So how do we calculate the length of the line by treating it as the hypotenuse 
ofa right triangle? Well, we're trying to find the length of the hypotenuse, and we 
know the lengths of the other two sides. So what we need to do is square each of 
the other two sides, add them together, and take the square root of the result. 
That will give us the length of the line. To get the lengths of the nwo sides, we 
need to calculate the changes in the x and y coordinates by subtracting the 
starting x from the ending x and the starting y from the ending y, like this: 

x_ change = x start - x end; 
y_change = y_start — y_end;] 

Then, co Pet the distance along the hypotenuse, We WILSt sQuare cach ot these, 
add the sums, and take the square root, like this: 


distance = sqrt(x_change*x_change + y_change*y_change) 
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Figure 7-18 The line from Figure 7-16 a5 the 
hypotenuse of a right triangle, The changes 
in the x and y coordinates along the length of 
the line are the other two sides 


where sqrt is a standard library function that we can call to obtain a square root. 
Thus we can measure the distance from one end of the line in Figure 7-16 by 
hrst calculating the change in x (which is 2) and the change in y (which is 5), 
then performing the necessary Pythagorean calculations: 

distance = sqrt(2*2+5*5) 


Or 


distance = sqrt(4+25) 
or 

distance = sqrtt29) 
or 

distance = 5.385 


Thus the length — or magnitude — of the line in Figure 7-16 ts 5.385 
Cartesian units. (In the above expressions weve observed the mathematical 
convention that multiplication operations are performed before addition 
operations unless otherwise noted. Since C and C++ — as well as most other 
programming languages — observe this convention when evaluating expressions, 
we dont have to worry that the operations will accidentally be performed in a 


ditterent order.) 
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Note that most of the concepts that weve discussed above apply to three- 
dimensional Cartesian space as well. A three-dimensional direction vector is the 
same as a two-dimensional vector, except that it has three numbers in it, 
representing the change in the x, y, and z coordinates along a given length of 
the line. Needless to say, these are referred to as the x, y, and z components of the 
VECTO. 

Now that we ve Foren down SOITLE basic ¥ector CONCEpTS, We Can Move On (oO a 
related topic that will alse be very important in the programs that we create in 
this boak. That's the concept of polar coordinates. 


Polar Coordinates 

When dealing with both two-dimensional planes and three-dimensional space, 
its important to be able to locate points within those planes or spaces. We've 
already discussed one method for doting so, the so-called Cartesian coordinate 
Sy¥S0em. But there's ad second method that 1s also commonly used, and that will 
sometimes be More relevant CO Our Purposes. That's the polar coordinate sVstem. 

Youve probably used the polar coordinate system on a number of occasions, 
In fact, when not programming graphics on the screen of a microcomputer, you 
may find thar you use the polar system far more often than the Cartesian, For 
Instance, when YOu tell somebody that in order To mee where they Want TO pO they 
need to drive north for 50 miles, you are telling them how to locate their 
destination in terms of polar coordinates. 

In a polar coordinate system, all points are located relative to an arbitrary 
origin point along a line, Because this line has a direction and a length, or 
magnitude, it is sometimes called a vector. And, in fact, it can be measured 
exactly as we measured lines in the last section of this chapter, using a direction 
vector and a magnitude. However, there are other ways of denoting the direction 
in which this line is pointing besides a direction vector. 

A compass, such as the one in Figure 7-19, is a simple example of a polar 
coordinate system. The center of the compass is the origin of the coordinate 
system and the needle is the line used to designate polar directions. With a 
compass, the direction of the line ts usually designated as north, east, south, west, 
or some point between two of those directions. To locate a point using a 
compass, we give the current position of the compass, the direction of the line — 
that 1s, the needle — and the distance along the line at which the point can be 
found. (This distance can be expressed in any unit with which the listener is 
familiar, such as miles or feet or nanometers, though some units are probably 
more appropriate for identifying certain points than others.) Thus we might say 
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Figure 7-19 A compass is 4 simple example of 2 polar 
coordinate system 


that a point lies 37 kilometers from our current compass location in a north- 
northeasterly direction. 

Probably the most common way to designate the direction of a line in a polar 
coordinate system, though, is to measure the angle of the line relative to the 
origin. One of the most familiar systems for measuring angles is the 360-degree 
circular system. The degree was believed by the ancient astronomers to be the 
distance that the vector berween the sun and the earth rotated every day, relative 
to the “fixed” stars, (If the year had been 360 days long, as the ancient 
ASTPONOMErS believed, they would've been More oF less COrect, but their 
calculations were slightly off.) Figure 7-20 shows a 360-degree circle surrounding 
an origin point, with a line connecting the origin with another point to its right. 
The length, or magnitude, of the vector is 5 units. (These units belong to a 
completely arbitrary system that weve made up on the spot, though if we used 
them consistently — the Way that inches, Meters, and Pall sees are used ——— they 
could actually serve as a satisfactory unit of measurement for vector magnitudes 
and other purposes.) Since we have placed the O-degree point where it 
traditionally goes, straight above the origin, and have placed all the other points 
clockwise around the circle, we can say that the point ts 10 units along a 90- 
degree vector from the origin. 
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Another system for measuring angles is the so-called radian system. This 
system is preferred by mathematicians since, unlike the degree system, it actually 
has something to do with the properties of a circle. You'll recall from geometry 
class (even if geometry class is now a distant memory) that the radius of a circle is 
the distance from the center of a circle to its circumference. A radian is a measure 
of the circumference of a circle that is equal in length to the radius. Because — 
heres the geometry again — the circumference of a circle is equal to two times pi 
(3.14...) squared, the number of radians in the full circumference of a circle is 
rwo times pi, or 6.28... (The three-dor ellipsis, youll recall from that same math 
class or another you took even earlier, tells us that this number is a decimal that 
we are only approximating with the digits actually printed on the page. From 
now on, well generally round off such numbers and not worry about the 
ellipses.) Figure 7-21 shows the same point along the same vector as in Figure 
7-20, but we have now translated the angle of the vector into radians. A radian is 
equal to 5/.2946 degrees. In radians, therefore, the vector ts pointed at an angle 
of 1.57. To translate from degrees to radians, we divide the number of degrees by 
57.2948, To translate back the other way, from radians to degrees, we multiply 
the number of radians by 57.2948. 





3.14 Rodians 


Figure 7-20 A point in a polar coordinate Figure 7-21 A point ina polar 
system is 10 units from the ongin alang a coordinate system 10 units from the 
90-degree vector Origin along 2 1.57-radian vector 
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Polar Direction Vectors 

Por polar coordinate systems to be useful to us in creating three- (or two-and-a- 
half-) dimensional computer games, we must be able to combine them with a 
Cartesian coordinate system. The easiest way to do this ts to use standard 
Cartesian direction vectors to describe the direction between the origin and a 
point within a Cartesian plane. However, we'll also need to be able to describe 
directions in terms of angles, using either degrees or radians (or, eventually, a 
system that we invent for ourselves), So we'll need a method of translating back 
and forth between angles and direction vectors, We'll see how to do this in a 
Moment, 

Figure 7-22 shows a two-dimensional polar coordinate system superimposed 
over a two-dimensional Cartesian coordinate system. Weve conveniently placed 
the origin of the polar coordinate system at the origin of the Cartesian system. 
This is generally the best place for it. Even when we must deal with polar 
coordinate systems that are not at the origin of our Cartesian coordinate system, 
well move them to the origin before performing any important mathematical 
operations on them, then move them back after we're done. 

The position of any point within a system like this can be designated in two 
different ways. It can be designated according to its Cartesian coordinates, or it 
can be designated by the direction and magnitude of a line forming a vector 
between the point and the origin. For instance, the point in Figure 7-22 is at 
coordinates 3,0. How do we designate this as a vector? Well, the distance from 
the origin to the point is 3 units, so we can say that the vector from the origin to 
the point has a magnitude of 3, Along thar length, the x coordinate of the vector 
changes from 0 to 3, and the y coordinate of the vector changes from 0 to 0 
(which is co say that it doesnt change at all). Thus we can say that the direction 
of the vector is 3,0. When we've said that the point lies on a vector with a 
direction of 3,0 and a magnitude of 3, we've completely described its position 
relative to the origin, just as though we had given its Cartesian coordinates. 

Similarly, the point in Figure 7-23 lies at coordinates 7,5, Weve drawn a line 
from the origin to this point, The direction and length of this line constitute a 
vector from the origin to the point and can be used to describe the location of 
the point. The direction of the line can be expressed by giving the change in the x 
and y coordinates of this line along a given length of it, Earlier, we calculated this 
change by subtracting the starting x,y coordinates from the ending x,y 
coordinates. In a polar coordinate system, however, the starting coordinates will 
always be 0,0, since the line extended to a point in the system always starts at the 
origin. So the direction vector for the line can simply be expressed as the 
coordinates of the point to which it extends: 7,5. 
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Figure 7-22 A polar coordinate system superimpose 
over a Cartesian coordinate system 





We can calculate the magnitude of the vector using the Pythagorean method 
that we used earlier. Once again, however, it's not necessary to first subtract the 
starting from the ending coordinates of the line to get its length, because it starts 
at 0,0. So we can just use the x,y coordinates of the point as the x.y lengths of the 
line. We can measure the distance from the origin to the point at 7,5 with the 
calculation 
distance = sqrt(7*7+5*5) 
or 
distance = sqrt(49+25) 


OF 
distance = sqrt(74) 


or 
distance = 8.602 

Thus the magnitude of the vector between the origin and the point at 7,5 is 
8.602. And the direction of the vector, expressed in terms of the Cartesian 
coordinate system, is 7,5. Thus we can describe the point in polar terms as being 
at a distance of 8.602 from the origin along a vector of 7,5. This may seem like 
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Figure 7-23 A point at coordinates 7,5 from the origin 


an unnecessary amount of information, since merely the numbers 7,5 suffice to 
express the position of this point within a Cartesian coordinate system. But bear 
in mind that we can also express the vector as any equivalent ratio: 14,10 or 
28,20 or even 3.5,2,5. And this flexibility allows us to perform translations from 


vectors to angles. To see how, let's look at the concept of the unit vector. 


The Unit Vector 
A line can have any positive magnitude and any possible direction vector, There 
is, however, one special direction vector associated with a special length of line 
(or portion of a line). It is the vector measured along a single Cartesian unit of 
the length of a line and ir is known, logically enough, as the unit vector. It has 
special properties, a few of which we are going to mention here. 

Any vector can be converted into a unit vector simply by dividing both the x 
and y components of the vector by the magnitude of the line along which the 
vector was originally measured, This is called normatizing the vector. It is done 
like this: 
normalized_x =x/ magnitude; 
normalized_y = ¥ i magnitude; 


where x and y are the x and y coordinates of the end of a line that starts at the 
origin, magnitude is the distance from the origin to the end in Cartesian units, 








CHAPTER SEVEN ‘Space: The Final Frontier 


81376,.58126 











Figure 7-24 4 unit vector of 81476, 58726 


and normalized_x and normalized_y are the normalized coordinates of the line's 
direction vector. 

For instance, the vector to the point in Figure 7-23 was 7,5 and the magnitude 
of the vector was &.602, so we can normalize this vector by dividing both the x 
and y components of the vector by 8.602, like this: 


normalized_x = 7 / 8.602; 
normalized_y = 5 / 8.602; 


If you performed these calculations, you would learn that the unit vector for 
the line that goes from the origin of the Cartesian coordinate system (or, for that 
matter, avy Cartesian coordinate system) to the point at coordinates 7,5 is 
.81376,.58126. (See Figure 7-24.) 


The Unit Circle 


If we draw all the possible points that are one unit away from the origin of a 
Cartesian coordinate system, as in Figure 7-25, they will form a neat circle 
around the origin. The circle is called a unit circle, because its radius 1s precisely 
one Cartesian unit. Every possible line extending one or more units from the 
origin crosses the unit circle. And if we measure that vector of a line along the 
portion of the line that extends from the origin to the unit circle, we will obtain 
— obviously — a unit vector, If you think abour it for a second, you'll see that 
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Figure 7-25 A unit circle around the origin of a Cartesian 
coordinate system 


the x,y components of this unit vector are also the Cartesian coordinates for the 
point at which the line crosses the unit circle. 


Rotating a Point 
For those of you who didn’ fall completely asleep during the foregoing burst of 
heavy mathematics, | have a (possibly) unexpected gift. | am going to show you 
how to use the coordinates at which a line crosses the unit circle to create your 
own three-dimensional world. This may seem like a pretty spectacular bonus to 
receive from a pair of numbers in a Cartesian coordinate system, but the concept 
of the normalized coordinates of a unit vector are at the heart of every Hight 
simulator and virtual reality program on the market. The normalized coordinates 
of a vector — the coordinates at which the vector the unit circle — can be 
used to translate back and forth between angles measured as degrees (or radians) 
and Cartesian direction vectors, So special are the x and y components of the 
normalized direction vector that they have been given names: They are the cosine 
and sine, respectively, of the angle at which the vector extends from the origin. 
Even if you slept through trigonometry (if not through the first part of this 
chapter), you probably remember the terms cosine and sine: However, you 
probably remember them in terms of right angles. After all, che very term 
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“trigonometry comes from an outmoded word meaning “triangle.” And, indeed, 
the sine and cosine we have stumbled upon at the point where a vector crosses 
the unit circle are the selfsame sine and cosine that you learned about tn trig 
class. In fact, if you remember enough of your trig, you can probably see how 
these two different ways of looking at sine and cosine are actually the same, since 
its pretty easy to find right triangles ina Cartesian coordinate system (as we did a 
moment ago, when we used the Pythagorean theorem to calculate the magnitude 
of a vector). However, were not going to discuss the theory of sines and cosines 
at any greater length in this chaprer — youve had enough mathematics to 
stupefy a rhinoceros. 

Standard mathematical algorithms for calculating sines and cosines can be 
found in any book on trigonometry. We wont be going into them here because 
our C/C++ compiler is supplied with standard library functions (the prototypes 
for which are in the header fle MATH.H) for calculating them. These library 
functions are slow, but they're good enough for the demonstration programs that 
we ll be writing in this book. Later we'll develop our own high-speed sine and 
cosine routines (though we wont use the standard mathematical algorithms for 
doing so). 

For our purposes, the most important thing about sines and cosines ts that 
they allow us to translate from an angle to Cartesian coordinates in space. And 
this in turn will allow us to take a point at a given set of coordinates relative to 
the origin and rotate it around the origin by any number of degrees or radians. 
(As it happens, the standard library sine and cosine functions that come with our 
C/C++ compiler expect an angle to be measured in radians. ) 

And this leads us to the topic with which we will finally wrap up this chapter 
on mathematics: coordinate transformations. 


Coordinate Transformations 


We will generally deal with three- (and two-and-a-half-) dimensional scenes in 
terms of the Cartesian coordinates of points within those scenes. As we saw 
earlier in this chapter, a polygon-hll Hight simulator deals with three-dimensional 
scenes in terms of the three-dimensional x,y,z coordinates of the vertices of 
polygons. As well see in the mext chapter, a maze can be dealt with in terms of 
the two-dimensional x,y coordinates at which walls and objects are placed within 
the Inaze. 

In both Hight simulators and maze games, the secret of creating the illusion of 
movement ts to move a point realistically in nwo and three dimensions. Moving a 
point within two- and three-dimensional coordinate systems 1s called 
transforming the point. There are primarily two ways in which we will want to 
transform points: the first is to translate them and the second is to rotate them. 


255 
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Translating a Point 


Translating a point means, simply, to move it from one place in the coordinate 
system to another along a straight line. Generally, a transformation ts expressed in 
terms of how many Cartesian units we want the x and y coordinates of the point 
to change during the translation, Actually translating a point is a simple matter of 
adding these values to the current x,y coordinates of the point, like this: 


new_x = old x + x_trans; 
new_y = old_y + y_trans; 


where old_x,old_y are the original coordinates of the point, trans_x,trans_y is the 
distance that we wish to move the point from its original position, and 
new_x,new'_y are the coordinates of the point after the translation. For instance, 
in Figure 7-26, the point 7,8 has been translated by -2,3 units to 5,11. 


Rotating a Point 

Rotating a point is somewhat more complex than translating it. However, there 
are standard formulas for doing so, based on the sine and cosine functions. Here, 
for instance, is the formula for rotating a point to a given angle relative to the 
origin of a Cartesian coordinate system: 


new_x = old x * cosine(ANGLE) - old_y * sine(ANGLE); 
new yy = old_x * sine(ANGLE)+ old_y * cos (ANGLE); 


where olfd_x,old_y are the original coordinates of the point, ANGLE is the angle 
that we wish to rotate it around the origin (expressed in whatever unit the sine 
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and cosine functions are expecting), and new_x,rtew_y are the coordinates of the 
point after the rotation, This rotation is always performed around the origin of 
the system. If you wish to rotate a point around some point other than the origin 
of the system, you must first translate chat point relative to the origin by the 
amount that the center of the rotation is displaced from the origin. That's a 
simple matter of subtracting the coordinates of the center of rotation trom the 
coordinates of the point (or adding the negative of the coordinates, which comes 
to the same thing). Then perform the rotation as described above and add the 
displacement back to the newly rotated coordinates. Here is one way in which 
this might be done: 


temp_x = old_x = center_y; 

temp_y = old_y - center_y; 

new x = temp x * cosineCANGLE) - old_y * sineC ANGLE); 
new_y = temp_x * simeCANGLE)+ = old_y * cos( ANGLE); 
new xX += center_x; 

new _y += center_y; 


where center_x and center_y are the coordinates of the point around which we 
wish to rotate the point at ofd_x,eld_y by ANGLE, and temp_x,temp_y are 
temporary value holders. The rotated position of the point will once again be at 
Hew! ynet!_x. 


Three-Dimensional Rotation 

We can also rotate a point in a three-dimensional coordinate system, but this is 
really just a matter of performing three separate pwo-dimensional rotations, 
There are three different axes in a three-dimensional coordinate system — x, y, 
and ¢ — and any two of these can be said to describe a two-dimensional plane. 
When we perform a two-dimensional rotation, as we did above, we are rotating 
the point in the x,y plane, that is, the plane formed by the x and y axes. Bur we 
can also rotate points in the x,z plane (the plane formed by the x and z axes) and 
the yz plane (the plane formed by the y and z axes). To rotate an object three- 
dimensionally, we must rotate it separately in each of these planes. (We can also 
think of this as rotating the point around each of the three coordinate axes, where 
rotation in the x,z plane is rotation around the y axis; rotation around the x,y 
plane is rotation around the z axis; and rotation around the y,z plane is rotation 
around the x axis.) 

The amount that this poinr ts to be rorared should be expressed by three 
angles: the angle for rotation around the x axis (rotation in the y,z plane), the 
angle for rovation around the y axis (rotation in the x,z plane), and the angle for 
rotation around the z axis (rotation in the x,y plane), Here is a formula for 
rotation around the x axis: 
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new_¥ = old y * cosineCANGLE) — old_z * simet ANGLE); 
new_z = old_y * sinme(ANGLE) + old_z * cosine (ANGLE); 
new x = old_x; 


Here is the formula for rotation around the y axis: 


new_z = old_z * cosine(ANGLE) = old_x * simeCANGLE); 
new_x = old_z * sine(ANGLE) + old_x * cosine(ANGLE); 
néw_y¥ = old_y 


And here is the formula for rotarion around the z axis: 


new x = old_x * cosine{ANGLE) — old_y * sime(ANGLE?}; 
new_y = old_x * sinmeCANGLE) + old_y * cosine( ANGLE); 
new_z = old_z; 


Youll notice that the formula for rotation around the z axis is identical to our 
earlier formula for two-dimensional rotation, since this is also rotation in the x,y 
plane that we normally use for pwo-dimensional Cartesian coordinates. 


Let 'Er Rip 

Thats enough mathematical background for now, We'll pick up additional math 
as we go along, building on the concepts that were introduced in this chapter, 
Now that we have the ability to translate points in two- and three-dimensional 
coordinate systems, we can start writing some two-and-a-half-dimensional maze- 
generation code, which will simulate three-dimensional motion through a maze 
without quite going all the way to the third dimension, In the next chapter, we'll 
stumble our way into the newest, most exciting frontier of all: ray-cast graphics. 
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n the more than two decades since Nolan Bushnell unleashed 
Pong on an unsuspecting world, video games have become 
increasingly more realistic. Pong featured a large white pixel 
being barred back and forth by a pair of horizontal lines, in a 
ee ee" crude simulation of Ping-Pong. If the game were rereleased 
ee it would probably feature a pair of animated players knocking a high- 
resolution ball back and forth across a texture-mapped table. Two decades trom 
now, a hologram of the rwo players may pop out of the computer and into your 
living room. Watch out for that backstroke! 





Maze games have not escaped this tidal wave of increased realism. Players 
demand maze graphics that are both vivid and fast. The challenge facing us as 
programmers is to come up with a method for depicting exceptionally vivid 
mazes that is not so complicated that it slows the resulting animation to a crawl. 
Unfortunately, realism and speed are often incompatible. By and large, the more 
realistic computer graphics are, the longer it takes to draw them. 

So for the moment, let's forget about speed. Let's find the most realistic 
possible method of generating computer graphics, then fnd a way to speed it up. 
We may sacrifce a few elements of realism when we start stripping our maze- 
generation algorithms down for speed. Bur, if we play our cards right, the game 
players will never notice. 
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soaking Up Rays 


What's the most realistic method of creating computer graphic images? That's 
hard to say, [here are several techniques now available for generating realistic 
images On a computer screen, and you can easily start an argument among 
graphics programmers by asking which ts best. However, the best-known method 
of generating realistic computer graphics is almost certainly ray tracing. 

The very name “ray tracing” has taken on nearly magical connotations in 
recent years. Even people who dont know a Hoppy disk from a frisbee can spot 
the ray-traced animation sequences in movies like Beauty and the Beast. Ray- 
traced images seem to glow with a vividness that is almost otherworldly. 

Surely a program that creates such wonderful graphics must itself be an 
amazingly complex piece of code. Only the most brilliant programmers could 
possibly dream of writing such a program, right? 

Well, no. Ray tracing may create beautiful images, but the ray tracers 
themselves are marvelously simple, at least in concept. Some complications result 
when programmers add clever tricks to the ray-tracing code in order to make the 
images render more quickly. Burt the basic algorithm underlying ray tracing is 
very straightforward and easy vo understand. To prove tt, well take a look at how 
ray tracers work. 


Looking at the World 
Take a look at the world around you. What do you see? Tables and chairs? Trees 
and houses? A desk with a microcomputer on top? 

In a sense, the answer is: None of the above. No matter what you think you 
are seeing, what you are reafly seeing is rays of light. 

Sight is the most intense of human senses, the one to which the largest portion of 
our brain is devoted, Sight begins when rays of light pass through the lenses of our 
eyes and strike photosensitive nerves inside them. These nerves pass information 
about those rays to our brain, which process that information to produce the images 
that we see. All of the information in that image comes from rays of light that are 
either bouncing off or being created by the objects at which we are looking. 

This may seem like an obvious statement, yet it's easy to forget the important 
role that light plays in our visual system. Objects such as the sun and 
incandescent lamps produce rays of light. These rays are colored by certain 
properties of the objects producing them. The rays then proceed to strike the 
surfaces of other objects, ar which point they are ether absorbed by the surfaces 
(causing those surfaces to become warmer) or reHected by them. Actually, most 
surfaces both reflect amd absorb light. Because this absorption ts usually selective 
— only certain colors of light are absorbed — the color of the reflected light is 
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Figure 8-1 Aray being traced backward from the viewer 
into the world inside the computer 


usually different from the color of the light that originally struck the surtace, 
When those reflected rays of light reach our eyes, we see only the colors that were 
not absorbed, which is why most surfaces in our feld of view have colors other 
than those of the object producing the light. 

For instance, when white light from an incandescent bulb strikes the surface of 
the filing cabinet sitting next to my desk, the surface absorbs the colors green and 
blue, leaving only red, Which is why the cabinet appears to be red when | look at 
it. If ] were to place a colored filter over the nearest lamp to filter the red out of 
the light, the cabinet might well appear nearly black, because it would absorb all 
of the colors that managed to get through the filter. 

In order to produce realistic images, a ray tracer tracks rays of light through a 
computer-simulated “world” and determines what color those rays would have 
after reflecting off of various surfaces. It then uses this information to determine 
the color of the pixels on the display. However, ray tracers don't attempt to trace 
every ray of light leaving every light source in the simulated world, or even a 
representative sample thereof. That would take much too long. Instead, ray tracers 
work backward, They start at the eyes of the viewer sitting in front of the computer 
and trace rays of light backward into the computer display (see Figure 8-1). 

How many rays of light does a ray tracer actually trace? Usually, a single ray 
for every pixel in the image being produced. One by one, the ray tracer traces 
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Figure 8-2 Each pixel on the display is given the color of 
the liaht ray that passes through it 


rays backward from the viewer's eyes through each pixel on the display into the 
simulated world inside. The pixels on the display are then given colors based on 
the color of the light source that tnitially produced the ray minus any colors 
absorbed by surfaces or filters that it encountered on the way (see Figure 8-2). 

Ray tracing is just about the simplest method ever developed for creating a 
graphic image, hyper-realistic or otherwise. Because each ray of light is tracked 
separately, it is not necessary to worry about inadvertently displaying hidden 
surfaces in the image or clipping portions of the image against the edges of the 
viewport, In fact, ray tracing has only one major drawback: It is slow, Tracing all 
of those rays takes time. There's no way that any ray tracer in existence today 
could be used to produce animated computer images on the Hy. Nonetheless, lets 
take a closer look at ray tracing, then hgure out how we can use some of the basic 
principles of the technique in a high-speed animation engine. In order to get an 
inside look at ray tracing, we'll spend the rest of this chapter developing an actual 
working ray tracer. 


A Ray Tracer of Our Own 


The first issue that we need to deal with in building a ray tracer is the way in 
which we will store the simulated world that we wane to trace. For the simple ray 
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Figure 8-3 The two types of objects supported by our 
ray tracer 





tracer that were about to write, theres no need to get fancy. Well store our 
“world” as a simple one-dimensional array, in which each element contains a 
description of one object in the world, The objects themselves will be simple 
shape primitives that can be described by a few parameters. To keep things as 
simple as possible, our ray tracer will only support nwo types of shapes: spheres 
and infinite planes (see Figure 8-3). 

Even this simple arrangement, however, introduces some complications in our 
program. The information needed to describe an infinite plane is quite different 
from the information used to describe a sphere. Thus we'll need to use the type 
of C/C++ structure known as a wnion to cram two different types of structures, or 
pointers to those structures, into a single element of the array, So we'll begin by 
creating separate structures for each type of object, then create a single type of 
pointer that can point at both of them. 

Before defining either of these structures, we ll define a special type of 
structure to hold numerical triplets, which we'll be using in a couple of ways in 
our object dehnitions. Well refer to this type of structure as vector_type: 
struct vector_type f 

double x,¥,z; 

I; 

One obvious use for this structure will be storing three-dimensional spatial 

coordinates, as described in the last chapter. Another use will be for describing 
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the spatial orientation of certain surfaces, as you'll see in our next definition. 
The definition for the infinire plane looks like this: 

struct plane_type f 
vector_type surface_normal; 


double distance; 
ty 


The vecter_type structure here represents the so-called surface normal of the 
plane. The surface normal is a line perpendicular to (or “normal to,” as a 
mathematician might put it) the surface of the plane. It can be represented by a 
three-number vector representing the change in coordinate values along a unit of 
the line, as shown in Figure 8-4, (See chapter 7 for a detailed discussion of 
vectors.) [his vector gives us the orientation of the plane in space. Since 
the plane is infinite — that is, it stretches away forever in two dimensions — the 
only other thing we need to know about it is where it is along the length of 
the surface normal, If we imagine the surface normal as a line stretching forever 
through space along one dimension, then an infinite number of infinite planes 
could be dispersed along its length. Thus we further define the plane with the 
variable distance, If we imagine that the surface normal intersects the 0,0 origin 





























Figure 8-4 The surface normal of a plane 
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point of our universe at some point in its infinite length, then distance represents 
the number of units from the the origin of the universe to the surface of the 
plane (see Figure 8-4). With those two values — the surface normal and the 
distance from the origin — we have completely described the infinite plane. 

We don't need to know the orientation of the sphere in space because a sphere, 
being symmetrical in all dimensions, has no real orientation. Put another way, an 
upside-down sphere looks exactly like a rightside-up one. (This is not true if the 
sphere has some sort of pattern mapped onto its surface, but we wont be using 
any surface patterns in our ray tracer.) What we need to know is the spatial 
location of the sphere — that is, the coordinates of the sphere’s center. It’s 
traditional in writing a ray tracer to use variables called { m, and n to represent 
these coordinates. We also need to know the radius of the sphere, in coordinate 
units. Here's the definition for the sphere structure: 
struct sphere_type f 

double L,m,n; // Center of sphere 

int r; ‘/ Radius of sphere 
Le 

Now that we have these two structures, well use them to create a type of 
variable that can point to both of these structures: 
union object_union { 

plane_type *plane; 

sphere_type “sphere; 

}; 

Finally, well create a structure that can be used to define an object in the ray 
tracers world: 
struct object_type f 

int type_of_object; 

int color; 

object_union obj; 

}; 

The first feld, type_of_object, is a number defining what type of object the 
structure represents. Well need to define constants representing the two types of 
objects that we will be tracing: 
const SPHERE=1; 
const INFINITE_PLANE=2; 


lf the type_of_object field is set to 1, the object is a sphere. If the qpe_of_object 
held is set to 2, the object is an infinite plane. Other values are not defined, 
though this ray tracer could easily be expanded to recognize other object types. 
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The eoler held will define the color that should be given to the surfaces of the 
object when they are fully illuminated. In practice, this will represent the 
maximum possible color of the surface; in most instances, the surface will be 
shown at least partially in shadow and wont achieve this maximum color, We'll 
have more to say about color in a moment. 

Finally, the eéj field can be either a pointer to a piene_type structure or a 
sphere_type structure, depending on which we want it to represent, Thus we 
define it as.an ebject_wnion structure. 


Low-Resolution Rays 


Betore we define the actual objects in the ray-traced world, let's talk a little about 
how were going to set up the video display. Since the game that we're going to 
write in this book will use the 320 by 200 by 256-color VGA graphics mode, the 
simple ray tracer that well develop in this chapter will use that mode too. 
Unfortunately, a ray-traced image usually requires a lot more than 256 colors, so 
we ll simplify our task by limiting the number of colors in the images that we 
produce. Instead of a full-color ray trace, we'll create a gray-scale ray trace. The 
VGA adapter can generate 64 different shades of gray, enough to create some 
nicely detailed and subtly shaded images. 

Well need to create a custom palette to hold these shades of gray. We'll store 
that palette in a char array, defined like this: 


char pall ?6éd; 


Then well put some code in the initialization portion of the ray-tracer 
program that will generate a gray-scale palette, In an RGB color system like the 
one used by the WGA adapter, all colors in which the levels of red, green, and 
blue are equal will appear to be gray. Since the VGA adapter can generate 64 
possible shades of each color component, it can display 64 possible shades of 
gray, from 0,0,0 to 63,63,63. Here's a for) loop that will put 64 shades of gray 
into the first 64 elements of a palette array: 
for Cint grey=0; grey<64; grey+t+) f{ 

pallgrey*3] = Cintigrey; 

pallgrey*3+1] = Cintigrey; 

pal(grey*S+2] = Cintigrey; 

} 


This loop iterates 64 times, one for each shade of gray. Since each palette entry 
is 3 bytes long, the actual index of each palette entry is found by multipying the 
loop index by 3. Only the first 64 palette colors are affected by this loop. We'll 
simply ignore the rest. 
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Defining the World 


Now that we have the necessary structures and a gray-scale palette, we can define 
the actual spheres and planes that will appear in the ray-traced image. Normally, 
this information would be placed in a file separate from the ray tracer itself, to 
facilitate the design of new images. But we dont have space in this chapter 
to construct the sort of parser logic that would be necessary for our ray tracer to 
read data in a separate file, Instead, we'll define the image right in the ray-tracer 
program itself. To trace a different image, you'll need to alter the file 
RTDEMO.CPP and recompile the ray tracer using the RFDEMO.PR] project file. 

We'll start by definining some constants. The first will tell us how many 
objects are in the world: 


const NUMBER_OF_OBJECTS=2; 


To keep things simple, the first world that we trace will have only two objects 
in it. Next we'll define the background color: 
const BACKGROUND _COLOR=14; 


The background color is the color given to those rays of light (and the pixels 
that they represent) that do not intersect either an object or a light source within 
the world. This color will appear in the background of the image, behind any 
objects. We have defined it here as VGA color 16, which in our gray-scale palette 
will be a fairly dark shade of gray, 

Next, well define the intensity of the ambient lighting in the scene. Ambient 
lighting is a diffuse, usually white, light that seems to come from all directions at 
once (see Figure 8-5). In the real world, it is light that has been scattered 
randomly after being reflected off many different objects, including molecules of 
air, Ambient lighting is the reason that shadows in the real world are rarely 
completely black (though in airless environments, such as the surface of the 
moon, ambient lighting is a much less important factor than tt is here on earth 
and shadows are very nearly lightless). If it werent for ambient light, the unlit 
portions of objects would be pitch black, something that usually only happens in 
completely darkened rooms, Ray tracers don't have the time to track all of these 
diffuse rays of light, so we need to dehne an intensity level for the ambient 
lighting that will automatically be used on all objects in the scene. Well represent 
the ambient level as a fraction berween 0 and 1, which we'll arbitrarily set to .27: 
const double AMBIENT_INTENSITY=. 27; 


OF COUrse, there MUST be al least one real light source in the scene, IF every 
surface was given only the ambient color, the image that we produced would be 
quite boring, But in the interests of keeping this ray tracer as simple as possible, 
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Figure 8-5 Ambient lighting is reflected liaht that seems 
to come from all directions at ance 


we Ll allow one and only one light source in the scene. And well need to create a 
vector_ftype constant in which we ll store the XViz coordinates of the light sO0urce 
within our imaginary world: 

const vector_type LIGHT_SOURCE={500,-200,150}; 


Now let's define the objects in the world. For our first trace, we'll only have 
two objects in the world, a sphere and an infinite plane. Here's how we'll 
initialize the plane: 
struct plane_type plane={ {0,-1,0}, ‘i Surface normal 

500 if Distance from origin 
4; 
This tells us (and the ray tracer) that the surface normal is pointed in a perfectly 
vertical direction, parallel with the y axts of the universe, as in Figure 8-6. (That's 
because the vector — 0,-1,0 — used to define the plane only changes in the y 
direction.) Ir also tells us that the plane is 500 coordinate units away from the 
universal origin along this vector, 

Here's how we define the sphere: 


struct sphere_type sphere={0,40,300, /f Coordinates of center 
100}; ‘/ Radius 


h 
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Surface normal (perpendicular to plane) 





Figure 8-6 The normal of the plane is pointed in a 





perfectly vertical direction 


This tells us that the sphere has a radius of 100 units and that the center of the 
sphere is located at universal coordinates 0,40,300. 

Next, we need to create an array of ofject_type structures to point to these 
objects. Heres the declaration of that array: 
struct object_type objectsCNUMBER_OF_OBJECTSJ={ 

{TSPHERE,56,(plane_type *) &sphere}, 

{INFINITE_PLANE,48,&plane} 

}; 

The number of elements in the array is nvo, since that’s how we've defined the 
NUMBER_OF_OBJECTS constant. The first element is set to point at the 
structure dehning the sphere. Despite the use of the wen statement in dehning 
the pointer to the object, its necessary to use a type override (in parentheses) to 
point it at the sphere structure, The type override corresponds to the first type 
used in the union; without the override, the compiler would complain that it 
couldnt perform the necessary data conversion. This declaration also tells us that 
the color of the sphere will be 56, which corresponds to the 56th shade of gray in 
our gray-scale palette, the one that we define as having RGB values 56,56,56, 

The second element points at the infinite plane structure. No override ts 
necessary here, since this was the first type of structure dehned in the waion 
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statement, This declaration also tells us that the plane is to be colored with gray- 


scale shade 48. 


A-Tracing We Will Go 


Now let's start tracing rays. Because were going to need some random numbers 
later on — you'll see why in a moment — we'll begin the maain() function of the 
ray tracer by initializing the random number generator: 





randomize); 


Then we'll initialize the gray-scale palette, using the for() loop that we developed 
earlier in this chapter. Next, well run through our standard mode 13h setup, 
setting the screen mode, saving the old screen mode, and so on. And we'll set the 
palette to the gray-scale palette that we ve developed: 

setpalette(pal,0,254); 


Well be needing a couple of vector_type variables, so well declare them here: 


vector_type rayvec,fraystart; 


The actual ray tracing will be performed inside a pair of nested for() loops, one 
to work through all of the POWs OT] the SCreen and the other to work through all 
of the pixels in a row. The index variables for these loops will be called psereen 
and xsereen, respectively: 


for (int yscreen=0; yscreen<200; yscreent+) i 
for (int xscreen=0; xscreen<320; xscreen++) f{ 


Follow That Ray 


Now we need a ray co trace. All that the ray tracer needs to know initially abour a 
ray is where it starts and the direction it's heading. Both of these things can be 
expressed by YCCTOMs, We'll Wace the reckon type variables FT ySlare and Pal PEC to hold 
this information. The variable neystart will contain the x,y,z coordinates of the 
start of the ray, and the variable rayee will contain the change in the x,y,z 
coordinates along a given length of the ray. (For a detailed discussion on vectors, 
see chapter 7. 

I's important here to remember thar a ray tracer tracks rays backward. Thus, 
while the rays that we track actually begin at a light source, we have to trace them 
as though they started at the eyes of the viewer. And where are the viewers eyes? 
Although a full-service ray tracer would allow us to place the viewer at any point 
in the world, looking in any direction, our simplifhed ray tracer will only allow 
the viewer to be placed at the origin of the world coordinate system, at 
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=— 8-7 The viewer's eyes are aligned with pixel 
pasition 160,700 ata distance of 100 units from the 


coordinates 0,0,0, looking straight down the z axis into the display. Well further 
assume that the viewers actual physical position places him or her a distance of 
100 coordinate units from the video display, looking directly at the pixel in the 
center of the display, as in Figure 8-7. (Actually, because the number of pixels in 
both the x and y directions on the display is even, there is no pixel that ts 
precisely in the center of the display, So we'll arbitrarily designate the pixel at 
coordinates 160,100 as the center pixel.) Let's store these hgures in some 
constants, because we ll be needing them later: 


const VIEWER _X=160; 
const VIEWER_Y=100; 
const VIEWER_DISTANCE=100; 


It would be fair to assign a value of 0,0,0 to the vector_type variable naypstart, 
since the ray ‘starts’ at the viewers eyes. But those numbers could cause 
problems later on, such as the dreaded divide-by-zero error. It’s just as fair to use 
the point where the ray intersects the computer's screen as the starting point. The 
coordinates of this point are in the loop index variables screenx and sereeny. 
However, we'll first subtract VIEWER_X and VIEWER_Y from xtereen and 
ysereen, to make these coordinates relative to the viewer's position: 
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raystart.x=xscreen-VIEWER_X; 

raystart.y=(yscreen-VIEWER_Y)*1.2; 

Why are we multiplying the y position by 1.2? In the 320 by 200 VGA mode, 
pixels on the display are not perfectly square. They are stretched by a small 
amount in the horizontal direction, making them 20 percent wider than they are 
tall (see Figure 8-8). This has the effect of making ray traced or otherwise 
computer-generated images appear a little square on the display. Multiplying the 
vertical coordinate by 1.2 compensates for this stretching, effectively unsquashing 
the images. 

We also need to determine the pixel’s z coordinate relative to the viewer. Since 
the viewer is looking straight down the z axis in the positive direction — that 1s, 
in the direction along which z coordinates increase — this will be equal to the 
distance between the screen and the viewer, which weve already stored in the 
constant VIEWER_DISTANCE: 
raystart.z=VIEWER_DISTANCE; 


We could also use these three values for neyeec, the direction vector for the ray, 
because they represent the distance that the ray has traveled along the segment of 
the ray from the viewer's eyes to the screen. However, many of the equations used 
in ray tracing require that the vector of the ray be expressed as a unit vector. 
You'll recall from chapter 7 that a unit vector is the change in coordinates along a 





Figure 8-8 Pixels on the mode 13h screen aré wider than 
they are tall 
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segment of a line equal in length to one unit of the coordinate system. It can be 
obtained by taking the vector of the line along amy length, then dividing the x, y, 
and z components of the vector by that length. 

We can calculate the length of the ray from the viewers position at 0,0,0 to 
the pixel at xvereen,yscreen by using a three-dimensional version of the 
Pythagorean distance equation introduced in chapter 7: 


(D =v6/a?+ be)? + c?) 
We can imagine that the distance berween the viewer and the screen is one side of 
aright triangle, while the distance from the center of the screen to the pixel is 
another side of that triangle. The distance from the viewer to the pixel, then, 
becomes the hypotenuse of that triangle (see Figure 8-9). We can calculate the 
distance like this: 


double distance=sqrt(raystart.x*raystart.xtraystart.y*raystart.y 
t+raystart.z*raystart.z); 





Then we can set neyvec equal to the unit vector between the viewer and the 


display like this: 


rayvec.x = raystart.x/distance; 
rayvec.y = raystart.y/distance; 
rayvec.z = raystart.z/distance; 
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Figure 8-9 The screen, a line from the viewer to the 
center of the display, and the ray from the viewer's eye 
form a right triangle 
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The ray tracing will be performed by a function called trace_ray(), which will 
take a pair of vectors as arguments and will return a gray-scale color value. This 
value will in turn be passed to a second function called plor(}, which will take a 
pair of x,y screen coordinates and a gray-scale value as arguments. Since the 
frace_ray() function returns a gray-scale value, we can pass the resulr of that 
function directly to plot(), like this: 


plot(xscreen,yscreen,trace_ray(rayvec,raystart)): 


All that remains for us to do in the main/) function ts to close rhe two fort) 
loops, pause until the user hits a key, and reset the ald video mode. 


The Heart of the Ray Tracer 


Obviously, the real heart of the ray tracer is in the trace_ray function. This 
function will loop through all of the objects in the world — at the moment, 
there are only two — and will perform calculations to see if the ray intersects the 
surface of any of those objects. If the ray intersects an object, the angle between 
the surtace intersected by the ray and the nearest light source will be calculated, 
This angle will be used to calculate a fractional value between 0 and | that can be 
multiplied by the gray-scale value of the surface to obtain the color of the ray. 
(The AMBIENT _INTENSITY value will be added to this fraction before the 
multiplication takes place.) If the angle is greater than 180 degrees, the surface is 
facing away from the light source and emfy the AMBIENT_INTENSITY is used 
to calculate the color of the ray. (If AMBIENT_INTENSITY is 0 — that is, if 
there is no ambient light in the scene at all — the ray will be assigned a gray-scale 
value of 0, meaning thar it is completely in shadow and should appear black in 
the scene. } The color of the ray 15 passed Ci) the calling function, where We plot 
the current screen pixel with that color. 

As simple as all of this is in concept, it will require some fancy mathematics to 
pull off. Fortunately, there are books available that provide most of the necessary 
math, so there's no need for us to reinvent the wheel, Several of these books are 
listed in the back of this book, if you want to extend the stmple ray tracer in this 
chapter into a full-fledged rendering program. Be warned, however, that these 
books can be pretty heavy going for the nonmathematically minded. (They ve 
already given the author of this book several headaches.) 

The first thing the rece_ray() function will do is look for intersections 
berween the ray and the objects in the scene. This requires that we find a pair of 
equations representing the ray and the object being tested. 

Since all of the objects in the scene are simple geometic primitives — spheres 
and planes — we can use standard math equations to represent these shapes. The 
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Figure 8-10 At time f, the ray of light has traveled f units 


ray of light itself is measured by a unit called ¢, which stands for time. Since the 
ray is presumably moving, albeit backward, it will reach different points in the 
scene at different times. The value ¢ represents the amount of time that the ray 
requires to travel ¢ coordinate units through the scene. If ¢ is equal to, say, 10, 
then the ray has traveled 10 coordinate units (see Figure 8-10). Thus, if we know 
that the ray encounters a surface at time f, we can calculate the actual coordinate 
position of that surface in space with these equations: 

xd * t + xO 

yd = t + yO 
zd * t + 20 


x 


r 
z 


These equations are said to be in parameterized form, because the value of the 
equations depends on the value of the variable ¢, Of course, this still doesn’t tell 
us whether the ray encounters any objects along the way. To determine that, we 
must combine the parameterized equation of the ray with the equation of a 
sphere or an infinite plane. The equation of a sphere with its center at 
coordinates 47,2 and radius r looks like this: 

See ee a ee eee 


where £m, and ware the three-dimenstonal coordinates of the spheres center and 
ris its radius (all information that we've stored in the ofject_type structure 
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representing the sphere), When combined with the parameterized equation of the 
ray, this becomes: 
(xd® + yd + 2d©) * t© + 2 *(xO*xd + yOtyd +20*2d) * t + (x02 + yO? + 
74) - 120 

So what are we supposed to do with this equation? If you remember your high 
school math, you may recognize that the equation above is a quadratic equation. 
This is quite fortunate, because there's a standard formula — known, sensibly 
enough, as the quadratic formula — for solving quadratic equations. Actually, 
there are rwe formulas, because every quadratic has two solutions, known as the 
roots of the equations. A generic quadratic equation looks like this: 


atye + b®x + ¢ = 0 


In the equation above, the term thar is multiplied by ¢° is a, the term that is 
multiplied by fis 6, and the term that isnt multiplied by anything is « To find 
the roots of a quadratic equation, we hrst must calculate its aiscrenimant. We do 


that with this formula: 
discriminant = be = 4¥*¥4*c 


Once we have the discriminant, we can calculate one of the two roots with this 
formula: 


root) = (<b + sartidiscriminant)) / 2*a 
We need only change one operator in thar formula to calculate the other root: 


root2 = (-b-sort(discriminant)) / 2%a 


The discriminant and the root of the parameterized equation of the ray and 
sphere tell us all we need to know about those two entities. [f the discriminant is 
equal to or less than 0, the ray never intersects the sphere. If the discriminant 
is positive, then the smaller of the two roots represents the time fat which the ray 
strikes the sphere. (If the sphere is transparent or semitransparent, the larger of 
the two roots would represent the time ¢ at which the ray passed through the 
opposite side of the sphere.) 

We can translate the time ¢ into the actual x, y, and z coordinates in space 
where the ray strikes the sphere using the equations we saw earlier in this chapter. 
Remember that time ¢ represents the time the ray takes to traverse ¢ coordinate 
units. The change in the x, y, and z coordinates along one unit of the ray is 
contained in the direction vector rayvec. Thus we need only multiply the x, y, and 
z portions of the direction vector by ¢t and add the result to the starting 
coordinates of the ray to find the position at which the ray strikes the sphere: 
loc. x=raystart.x+rayvec.x*t 


Loc. y=raystart.ytrayvec.y*t 
Loc. z=raystart.z+rayvec.2*t 


ay 
| 


i 
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Figure 8-11 The coordinates at which the ray strikes the 
surface of the sphere 


All thar remains to do now is to find the angle berween the surtace of the 
sphere at the point of intersection and the rays coming from the light source, so 
that We can acjust the color of the sphere's surtace and hind UT what color co 
paint the pixel that the ray passes through. To find the vector of a line normal to 
— thar is, perpendicular to — the surface of the sphere at the point where the 
ray strikes it, we must subtract the coordinates of the center of the sphere (which 
we ll call £ m, and #) from the coordinates of the pont at which the ray strikes its 
surface (which we'll call x, » and 2) and divide the result by the radius of the 
sphere (which well call r): 
normal.x = (x - Ld/r 


normal. ¥ Cy = mvp 
normal.z = (z - nj/r 


This gives us the coordinates in space at which the ray hits the sphere (see 
Figure 8-11), Obtaining the actual angle berween the normal at the sphere’s 
surface and a ray of light coming from the light source ts a bit more complicated. 
Well talk more about the details of this sort of lightsourcing in a later chapter. 
For now, well simply provide a function called feftsewrce() that will take as 
Parameters the eray-scale color of the surtace, the location of d poInt On that 
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surface, and the normal of the surface at that point, and return the lightsourced 
value of the color at that point, which will then be used as the color of the pixel, 

Finding an intersection between the ray and an infinite plane is actually a little 
simpler, which is certainly good news after all that math. The equation for a 
plane is: 


ax + by + cz +d = 0 


where x, y, and z are the coordinates of any point on the planes surface; a, b, and 
¢ are a direction vector of a line normal to — that is, perpendicular to — the 
planes surface; and d is the distance along that line from the origin of the 
universe co the plane. 

When combined with the parameterized equation of the line, this becomes: 


t = -(a*x0 + b*yO + c¥z0 + d) / Ca*xd + b*yd + c*zd) 


To solve this equation, we only need to plug in the appropriate values in place 
of the variables and we'll have the time fat which the ray strikes the plane. If the 
first part of this equation — a*x() + beyl) + cz — is 0, chen the ray is parallel to 
the plane and never strikes ir. If it is non-zero and the value of ¢ is positive, the 
ray intersects the plane. (It also intersects the plane if the value is negative, but it 
intersects it behind the viewer, where it cannot be seen.) We can then determine 
the angle between the plane at that point and the light source exactly as we did 
with the sphere, except that the normal vector for the plane is already known. 
(It's stored in the eéject_type variable representing the plane.) 

Now that weve covered the relevant math, let's write the face_nay() function. 


A Ray-Tracing Function 
Here's the prototype for the function: 
int trace _ray(vector_type rayvec,vector_type raystart) 


We tl begin the function by declaring a few relevant variables: 


int color; /f The color of the ray 
double a,b,c,d,%1,¥1,21,%.¥-Zs ‘/ Temporary values 
double t,t0,tl,rootl,root2,discriminant; // Temporary values 
double X0,Y0,20,Xd,¥d,2d,dot,dot2; ‘i Temporary values 
double prev_t=MAXDOUBLE; ‘/ Previous intersection 


vector_type norm,loc,plane_loc,pixel,diff,temp,plane; // Temp vectors 


Most of these will be temporary placeholders for values already contained 
cither in the parameters passed to the function or in the wbject_type array. [he 
double-precision variable prev_t is set to MAXDOUBLE, the largest double- 
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precision variable that the compiler can deal with without losing precision, for 
reasons that well explore in a moment. 

The variable cofer will hold the gray-scale color that we'll be returning to che 
calling function. Initially, we ll set it to the background color: 


color=BACKGROUND_COLOR; 


If no intersections are found between the ray and an object, this value will be 
passed unchanged to the calling function. 

The rest of the function will be structured as a for() loop that will iterate 
through all of the objects in our ray-traced universe: 


for (int ob=0; ob<NUMBER_OF OBJECTS; ob++) ¢ 


[Inside this loop we re going to place a large sutco() starement, in which each case 
will handle one of the types of objects that weve defined in our world structure. 
Since only two types of objects have been defined — spheres and infinite planes 
— only cwo eases will be necessary: 


switch Cobjectslobl.type of object) f 


The tpe_of_object held tells us what type of object each element of the objects 


array represents. For our first case, we ll check to see tf its an inhnite plane: 


ease INFINITE_PLANE: 


If it wan infinite plane, well set the veetor_type variable norm equal to the planes 
surface normal: 


norm=objectsCob].obj.plane->surface_normal; 


Well further set the variables a, 4, c, and @ equal to the x, y, and z elements of the 
normal and the distance berween the plane and the origin: 


a=norm. x; 
b=norm. ¥; 
c=norm.z; 
d=objectslobl.obj].plane->distance; 


And well set the variables X0, YO, and #0 to the starting coordinates of the ray 
and the variables Xa Fal and 7d to the direction vector of the ray: 


XOsraystart.; 
YO=raystart.¥; 
(Q=raystart.z; 
Xd=rayvec.x; 
¥d=rayvec.y; 
id=rayvec.z; 


We can then calculate the first portion of the combined equation of the line and 
plane: 


et 


= ee 


>| 
et 
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double vd=a*Xd+b*¥dec*lZd: 


If chis isnt equal to 0, well continue: 
if (vd!=0) f 


Then well calculate the second part of the equation: 
double vO=-(a*X0+b*7O0+e*2Z0+d) ; 


and derive the value of t 


t=v0/vd; 


This is where the variable prev_t comes tn. If the ray intersects more than one 
surface in the scene, we only want to know the color of the nearest one, since it 
will block the ray and keep it from striking the second object (unless the first 
surface is transparent, a possibiliry that we are not including in our ray tracer), 
The variable prev_¢ holds the distance to the last surface the ray struck. (Initially, 
we set it to the farthest distance possible, so that any objects that ic struck would 
be at smaller distances.) We check to see if ris both positive (so that we know the 
surface ts in front of the viewer) and smaller than prev_t before we continue: 


if ((t<prev_t)@&(ts=0)) 4 


If ¢ passes both tests, we set prev_t equal to the distance to this surface: 

prev_t = t; 

and calculate the coordinates in space of the intersection point, storing them in 
the vector_type variable loc: 


loc. x=XO0+Kd*t: 

Loc. y=YO+¥d*t; 

loc. z=Z0+Zd*t; 

To get the actual lightsourced color of the surface, we pass the color of the plane 
(stored in abjects/ob/.color) to the Jightsource() function: 


color=Lightsource(objectsCobl.color,loc,norm); 


And that's all we need to do if the object is a plane. Ac the end of the function, 
well return the value of color ro the calling function. 


Tracing a Sphere 
We follow a similar course of action if the object is a sphere: 


case SPHERE: 


We ser the variables Xr, Yc, and Zc equal to the coordinates of the cenver of the 
sphere, and Sr equal to the radius: 


282, 
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double Xe=objectsCobl.obj.sphere=->1L; 
double Yco=objectslobl.obj.sphere->m; 
double Ze=objectslLobl].obj.sphere-=n; 
double Srz=objectslob)].obj.sphere->r; 


Once again, we set AX), YO. and 40 equal to the starting point of the ray, and 

Ad, Ya, and “d to the direction vector of the ray: 

KO=raystart.x; 

YOoraystart.y; 

2Q=raystart.z; 

Kd=rayvec.x; 

¥d=rayvec.y¥; 

id=rayvec.z; 


Then we set the variables & and c equal to the b and ¢ components of the 
quadratic equation: 


b=2.0*(Xd"*(xX0-Xc)4+¥d*(¥0-Yo)+id*(70-2c)); 
c=CX0—2c}* (XOX d4CVO-Yed eC O-¥c)+020-2c)*(20—-Zc)-Sr*Sr; 


We then calculate the discriminant using the quadratic formula and check to 
see if its either 0 or positive: 


Vf (Cdiscriminant=b*b=-4*%c}>=0) +t 


If it is, we calculate the first and second roots of the equation: 


double sd=sqrt(discriminant); 
t0=(-b-sd)/2; 
tl=(=b+sd)/2; 


We then set ¢ equal to the smaller of sland rl: 


if (C(t0>O)||(tt>0)) 4 
if (tO>0) t=t0; 
if CltT<tORE(ti>=0)) t=t1; 


If cis less than prev_t, we calculate the position of the paint in space where the 
ray intersects the sphere and the surtace normal of the sphere at that point: 


if (t<prev_t) f 
prev_t=t; 


ff Caleulate the coordinates of intersection: 
loc. x=X0+Xd*t ; 
lLoc.y=YO+Yd*t; 
loc. z=Z0+Zd*t ; 


‘f Find the normal vector at that point: 
norm.x=ClLoc.w<Kel/Sr; 
norm.y=(lLoc.y-Yoi/Sr; 
norm.zZ=(loc.z-f¢)/Sr; 


(B) 
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Then we call the /ebtsource() function to get the color of the surface at thar 
point: 


color=Lightsource(objectsCoblJ.color,loc,norm); 


And thats it. The only thing left to do in the trace_nzyp() function is to terminate 
the loops and #//) and return the value of color to the calling function. 


The lightsource() Function 
We wont discuss the frghtsexree() function in detail, because we'll be covering 
lightsourcing in a later chapter. The prototype looks like this: 


int Lightsource(int color,vector_type loc,vector type norm) 
{ 


We begin by defining some variables: 


double newcolor; 
vector_type Lightvec; 
double integer; 


To obtain a vector from the surface to the light source, we subtract the surface 
location from the coordinates of the light source: 


Lightvec.x=LIGHT_SOURCE.x-Loc.x; 
lightvec.y=LIGHT_SOURCE.y-loc.y; 
Lightvec.z=LIGHT_SOURCE.z<loc.z; 


Then we calculate the distance to the light source using the Pythagorean formula: 


Long distance=sqrt(lightvec.x*lightvec.x+lightvec.y*Llightvec.y 
+lLightvec.z*lightvec.z); 


If the distance is 0, we fudge it up to | to avoid divide-by-0 errors: 
if (distance==0) distance=1; 

Then we use the distance to find the unit vector to the light source: 
double xlLight=(double)lightvec.«/distance; 

double ylight=(doubLe)lightvec.yidistance; 

double zlight=(double/Lightvec.z/distance; 

The standard method for calculating the intensity of light on a surface is to 
multipy the normal vector of the surface by the unit vector to the light source: 
double intensity=norm.x*xLlLight+norm.y*ylight+norm.z*zlight; 

This will give us a number berween 0 and 1 representing the intensity of the 
light. We add the ambient intensity to this value: 
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intensity+=AMBIENT_ INTENSITY; 


[f che result is greater than 1, we round it off to 1: 


if Cintensity=1.0) intensity=1.0; 


And we multiply the resulting intensity by the gray-scale color of the surface: 


newcolor=color* intensity; 


We dont want the edge berween shades of gray in the final image to be too 
sharp, since this can create a phenomenon known as “banding.” Since the gray- 
scale value obtained from the previous equation probably has a fractional value, 
we flip a virtual coin with the rendom() function to decide whether we should 
round that value up to the nexe integer with the cei) function or down to the 
previous integer with the floor) function, This technique is called dithering, and 
will give a randomly speckled look to the shading in the final image: 


if (modf{newcolor,@integer) * 10000 > random(10000)) newcolor=ceil(newcolor); 
else newcolor=floor(newcolor); 


Its possible that we just rounded a fray-scale value above the range allowed by 
our program, so we check for values greater than 63 and round them down to 63: 
if (newcolor>é63) newcolor=63; 

Finally, we pass the lightsourced color back to the calling function: 


return (int) newcolor; 
} 


The plot() Function 

The plot) function is so simple that its barely worth describing. We use the same 
formula that weve used in earlier chapters for calculating a video memory offset 
from a pair of coordinates: 


void plotCint x,int ¥,int color) 
{ 


int c; 
screenly*320+xJ=color; 


3 


The RTDEMO Program 


The complete text of the ray-tracing program, called RTDEMO.CPP, is in 
Listing 8-1: 
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Listing 8-1 The RTDEMO.CPP program 


ff RTDEMO.CPP Version 1.0 

‘/ Simple demonstration of ray tracing (in gray scale) 
if 

ff Written by Christopher Lampton 

if for Gardens of Imagination (Waite Group Press) 


finclude <stdio.h> 
Finclude <dos.h> 
Finclude <conio.h> 
finclude <stdlib.h> 
Finclude “screen.h" 
Finclude “pex.h" 
Finclude "math. h" 
Finclude “time .h" 
Finclude “yvalues.h" 


const RECTANGLE=1; 
const INFINITE_PLANE=2; 
const SPHERE=3; 


struct vector_type f 
double «,¥,z; 
}; 


struct plane_type f 
vector_type surface_normal; 
dowble distance; 

}; 


struct sphere_type f 
double L,m,n; // Center of sphere 
double r; ‘f Radius of sphere 
b; 


union object_union { 
plane type *plane; 
sphere_type *sphere; 
I; 


struct object_type f 
int type_of_object; 
Int color; 
ebject_union obj; 

I; 


const NUMBER OF OBJECTS=2; 
const BACKGROUND _COLOR=4; 
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const double AMBIENT_INTENSITY=. 14; 

const vector_type LIGHT_SOURCE={500,=-200,150}; 
const VIEWER_X=160; 

const VIEWER _Y=100; 

const VIEWER_DISTANCE=100; 


struct plane_type plane={ {0,-1,0}, f/f Surface normal 
500 // Distance from origin 
#5 
struct sphere_type sphere={0,40,300, // Coordinates of center 
1007 // Radius 


= 
is 


struct object_type objectsCNUMBER_OF_OBJECTSJ={ 
{SPHERE,34,(plane_type *) Espheret}, 
CINFINITE_PLANE,48,(plane type *) &plane} 

Is 


int trace_ray(vector_type rayvec,vector_type raystart); 

void plottint x,int ¥,int color); 

vector_type getloc(double t,vector_type rayvec,vector_type raystart); 
int Lightsourcetint color,vector_type loc,vector_type norm): 


int Image=135; 
char far *screen; 


wold maint) 
{ 
char pall?6éJ; 
wector_type rayvec,raystart; 


randomize}; 


for (int grey=0; grey<64; greyt+) f 
pallgrey*3] = Cintigrey;: 
pal(grey*34+1] = Cintdgrey; 
pallCgrey*S4#2] = Cintigrey; 

} 


int oldmode=*Cint *JMK_FPC(Om40,0¢49); // Save previous 
// vwideo mode 

screen=(char far *JMK_FPC(Oxa000,0>; 

setmode(0x13): ff Set mode 15h 

setpalette(pal ,0,256) ; 


els(sereen): 


for (int yscreen=0; yscreen<200; yscreent+) { 
for (int xscreen=0; xscreen<320; xscreent+) f{ 
raystart.x=xscreen-VIEWER_X; 
raystart.y=(yscreen-VIEWER_Y)*1.2; 
raystart. Z=VIEWER_DISTANCE; 
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cetinwrd from precedes Delite 
double distance=sqrt(raystart.x*raystart .xtraystart.y*raystart.¥ 
+raystart.z*raystart.z); 

rayvec.% = raystart.x/distance; 

rayvec.y = raystart.y/distance; 

Payvec.2 = raystart.z/distance; 
plot(xscreen,yscreen, trace _ray(rayvec,raystart)); 

} 
} 


‘/ Wait for user to hit a key: 
while ('kbhit()): 


setmodetoldmode); // Reset video and exit 
} 


int trace_ray(vector_type rayvec,vector_type raystart) 
{ 

int color; 

double a,b,c,d,xe1,¥1,21,%,¥-23 

double t,t0,tl,rootl,root2,diseriminant; 

double X0,70,20,%d,¥d,Zd,dot ,dotz; 

double prev_t=MAXDOUBLE; 

vector_type norm,loc,plane_loc,pixel,diff,temp,plane; 


color=BACKGROUND COLOR; 
for Cint ob=0; ob<NUMBER_OF_OBJECTS; ob++) { 
switch (objectsLobl.type_of_object) ¢ 
ease INFINITE_PLANE: 
norm=objectslobl].obj.plane->surface_normal ; 
a=norm.x; 
b=norm.¥; 
e=norm.2; 
d=objectsCobl.obj].plane->distance; 
XO=raystart.x; 
¥O=raystart.y¥; 
fO=raystart.z; 
Xd=rayvec.x,; 
Ydsrayvec.y¥; 
Ed=rayvec.2; 
double vd=a*Xd+b*VYd+c*Zd; 
if (vd!=0) f 
double vO=-Ca*x0+b*7¥0+c*204+d) >; 
t=v0/vd; 
if ((t<prev_tyee(t>=0)) f 
prev_t = t; 
Loc. x=xXU+Xd*t > 
Loc. y=¥O+V¥d*t ; 
loc. z=Z0+2d*t; 
color=Lightsource(objectsCob].color,loc,norm); 


—_——_—_- 
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break; 
case SPHERE: 
double Xc=objectsLobl.obj.sphere=->l; 
double Yc=objectsCob).obj.sphere—>m; 
double Zc=objectslLobl].obj.sphere=->n; 
double Sr=objectsCob].obj.sphere->r; 
XO=raystart.x; 
¥O=raystart.y¥; 
iO=raystart.z; 
AG=rayvec.x; 
¥d=rayvec.y¥; 
fd=rayvec.z; 
b=2.0*(Xd*(XO-KNcd+V¥d*(¥O-YoJ+2d*(270-Zc)); 
c=(X0—Kc)*CKO-Ke 40 YO-Yo)*CY0-¥e)4020—209"020-2¢e)-Sr*sr; 
if (Cdiscriminant=b*b-4"c)><0) { 
double sd=sqrt(discriminant); 
t0O=(-b-sd)/2; 
tl=(=b+sd) /2; 
if (CtOsO0)||Cti>0)9 £ 
if (t0e0) t=t0; 
if (Ctl<tO}Se(ti>=0)) t=t1; 
if (t<prev_t) f 
prev_t=t; 
Loc .x=X04+Kd*t > 
loc. y=¥0+Y¥d*t; 
Loc.z=20+Zd*t; 
norm. x=Cloc.“—Ked/Sr; 
norm.y=(Loc.y-Yeoo/Sr; 
norm.z=(lLoc.z-Zc)/Sr; 
color=LightsourcetobjectsCobl.color,loc,norm); 


} 
} 
} 
break; 
} 
} 
return color; 


} 


void plotCint x,int ¥,int color) 
{ 
int c; 


screenLy*320+xJ=color: 
} 


int Lightsource(int color,vector_type loc,vector_type norm) 
{ 

double newcolor; 

vector_type Lightvec; 

double integer; 
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carnerinea free srrevical purge 
Lightvec.x=LIGHT_SOURCE.x-loc.x; 
Lightvec. y=LIGHT_SOURCE.y-Loc.y¥: 
Lightvec.Z=LIGHT_SOURCE.2z-Loc.z; 
Long distance=sqrt(lightvec.x*lightvec.x+lightvec.y*lightvec.y 
+lightvec.z*lightvec.z); 
if (distance==0) distance=1; 
double xlight=(double)Lightvec.x/distance; 
double ylight=(double)lightvec.y/distance; 
double zlight=(double}lightvec.z/distance: 
double intensity=norm.x*xlight+norm. y*ylighttnorm.z*zlight; 
1f Cintensitys0.0) intensity=U; 
intensity+=AMBIENT_INTENSITY; 
if Cintensity>1.0) intensity=1.0; 
newcolor=color*intensity; 
1f (modt(neweolor,&@integer? * T0000 > random(10000)) newcolor=ceil(neweolor); 
else newcolor=floor(newcolor); 
1f (newcolor>63) newcolor=63; 
return (int? newcolor; 


To run the program, go to the directory called RAYTRACE and type 
RE DEMO, The image of a ray-traced gray sphere and plane will appear (see 
Figure 8-12), 

A second version of the program is available in that directory under the name 
RAY2. Type RAY2 and you'll see a second trace, with a larger number of spheres 
in several different shades of gray (see Figure 8-13). If you have a copy of the 
Borland C++ compiler, you might want to design some scenes of your own and 
recompile the tracer. 





Figure 8-12 The ray-traced sphere and plane 
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Figure 8-13 Ray-traced multiple spheres 


Extending the Ray Tracer 


If youre interested in pursuing the subject of ray tracing at greater lengths, there 
are a number of ways in which this ray tracer could be extended. Two of the most 
interesting extensions would be to add texture mapping and reflective surtaces. 
Then you could create one of the favorite images of the novice ray tracer: a 
reHective sphere hovering over an infinite checkerboard. 

You could also add additional primitive shapes, including polygons and 
toruses, out of which any number of complex images could be fashioned. If 
youre feeling really ambitious, you could add full-color capability to the ray 
tracer. If you have a graphics card capable of displaying 24-bit color (a common 
feature of most recent graphics cards), vou could even create 16-million-color 
pictures, with delicate shading and vibrantly colored surfaces. OF course, if you 
dont feel up to writing a full-Hedged ray tracer, you can always use one of the 
freeware and shareware ray tracers such as POVRAY, POLYRAY, or VIVID. 


Ray-Traced Mazes? 


50 are we going fo use ray-tracing techniques to create a maze game? Not exactly, 
As you may have noticed while using this ray tracer, it can take from several 
seconds (on fast machines) to several minutes (on slower machines) to trace a 
complete image. If we were to buckle down and optimize this program, we could 
make it considerably faster — there are a number of optimization techniques that 
can be used on ray tracers — bur ir still wouldn't be able to maintain the sort of 
frame rate required of a maze game. 
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Instead, we are going to take some of the principles used in this ray tracer and 
put together a brand-new technique for generating maze images, a technique that 
can be used to maintain quite a respectable frame rate. The technique that we'll 
be developing is sometimes referred to as nay casting. 
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ray tracer creates its miraculously realistic renderings by tracing 
an imaginary ray of light through every pixel in an image. That's 
a lot of rays. Even when creating a relatively low-resolution 
) |) mode 13h full-screen image, where there are 320 pixels in each 
lee’ of 200 rows, a ray tracer must trace 64,000 individual rays. That 
takes a lor of time. 





In a naive ray [racer such “LS the OPC Wit developed in the last chapter, each of 
these rays must be compared with every primitive object in the scene, which is 
even more time consuming. Industrial-strength commercial ray tracers use clever 
algorithms to avoid comparing the ray with objects far from its path, bur the 
number of comparisons between the ray and the objects in the scene is still 
usually quire large. 

If we are to come up with some sort of variant on ray tracing that can operate 
at speeds sufficient for real-time animation, well need to put the bulk of our 
optimizations into reducing the number of rays to be traced and reducing the 
number of comparisons that need to be made between rays and objects. With 
that goal in mind, let's do some brainstorming, 
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Reducing the Number of Comparisons 


To reduce the number of comparisons between rays and objects, it would be 
useful if we had a clear idea in advance about the sort of world the rays will be 
traveling through. A ray tracer can trace just about any kind of scene that a 
computer artist wants it to trace, but we dont necessarily need that versatile a 
renderer. In earlier chapters weve worked with a much more limited universe, 
one that consists of a floor, a ceiling, and a lot of cubes placed at hxed intervals to 
form the walls of a maze. So in this chapter well develop a renderer that can only 
work within such a universe, 


Reducing the Number of Rays 


We alsa Want to reduce the number of Pays tO be traced, ha we || place an even 
more radical limitation on our renderer. Instead of tracing a ray for every pixel in 
the display, well trace a ray for every vertical co/wmn of pixels in the display, In a 
full-screen-mode 13h image, this will reduce the number of rays to be traced by a 
factor of 200! 

That may sound like an impossible limitation, but it really isn't. In chapter 6, 
for instance, we created rexture-mapped polygons by drawing vertical slices of the 
texture one after another from the left side of the polygon to the right. The 
renderer that we create in this chapter will texture map the interior of an entire 
maze in much the same way: by dividing it up into vertical slices and casting a 





Figure 9-1a An adventurer in the maze. 
The arrows are the rays of llaht traveling 
from the scene to the adventurers eyes 
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ray along each slice to determine what textures lic along its path, The simplihed 
architecture that well be using, with walls laid down at right angles to one 
another, makes these simplified rendering methods possible, 


Casting Rays 


To see how this works, take a look at Figure 9-la, It depicts an intrepid 
adventurer standing in the middle of a maze, as viewed from directly above. 
(Since all you can see is the top of the adventurers head, youll have to take my 
word for it thac he or she ts intrepid.) The tip of the advenrurers nose tells us in 
what direction he or she ts facing. The arrows zeroing in on the adventurers face 
are the Tavs ot light emanating from the Maze SCENE, which form the adventurers 
held of view. 

Figure 9-lb shows the maze as the adventurer sees it — and as we will be 
drawing it in the on-screen viewport. The ray at the extreme left in Figure 9-1a 
corresponds to the column of pixels at the left edge of the viewport in Figure 
9-1b. Similarly, the ray at the extreme right in Figure 9-la corresponds to the 
column of pixels at the right edge of the viewport in Figure 9-1b. One of the rays 
of light in Figure 9-1a has been depicted as a dotted line. This ray corresponds to 
the dotted line drawn over one of the columns near the center of the viewport in 
Figure 9-1b, 

What do | mean when | say that a ray in Figure 9-la “corresponds” to a 
column in Figure 9-1b? Imagine that each ray of light is a snake, slithering across 



































Figure 9-1b The maze as seen by the adventurer 
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the Hoor and up and down walls in an arrow-straight line heading directly toward 
the adventurers eyes. From the adventurers point of view, each snake would 
appear to take a pertectly vertical path along a single column of his or her field of 
vision. The snake corresponding to the dotted line in Figure 9-1a, for instance, 
would appear to take a vertical path corresponding to the dotted column in 
Figure 9-1b, 

This means that we can take a single snake-like ray, “cast” it from the 
adventurers point of view, and follow it across Hoors, walls, and ceilings to 
determine all of the visual information needed to draw an entire column of pixels 
in the viewport. As in a ray tracer, well be following this ray as though it were 
moving from the adventurers eyes Into the scene, rather than vice versa. If we can 
develop a speedy enough algorithm for following the path of the ray and 
determining what lies along it, we should be able to render images of the maze 
fast enough for real-time animation. 


Follow That Ray 


We'll break our ray-casting algorithm into two parts. One of these parts will 
follow the ray across the Hoors and ceilings of the Maze, and the second will 
follow it along the walls. We'll refer to these two parts whimsically as the 
floorcasting and the walleasting parts. The wallcasting will be the easier of these 
two parts to implement ethciently, because the geometry of the maze only allows 
walls to occur at fixed locations, at the edges of the cube-shaped blocks that make 
up the maze, So well implement this part of the algorithm fest. 


Wallcasting 


The way in which we follow the ray as it encounters the walls of our maze Is 
heavily dependent on the way in which information about the maze ts stored in 
the computer's memory. So lers quickly review the maze representation that we ve 
been using throughout this book, In the course of this chapter, well expand on 
this storage system, creating additional arTays of variables to store the information 
that our ray-casting algorithm needs to draw the walls, Hoors, and ceilings of the 
Maze. 

Until now, we've represented our mazes using a two-dimensional array in 
which every element corresponds to a section of a maze grid, as depicted in 
Figure 9-2, A 0 value in an element of the maze array indicates that the 
equivalent section of the maze grid is empty (except, presumably, for the presence 
of a Hoor and a ceiling), A non-zero value in an element of the maze array 
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Figure 9-2 The two-dimensional maze arid and the array 
Alements that correspond to the sections of the grid 


indicates that the equivalent section of the maze grid contains a solid cube chat 
stretches from floor to ceiling and completely fills the grid section. The four 
vertical sides of each cube form the walls of the maze, 

This maze grid can be looked at as a kind of two-dimensional Cartesian 
coordinate system. Each grid location is identihed by a pair of numbers, which 
can be thought of as x,y coordinates. We can track a line across this grid of maze 
squares in the same way that we track lines across the pixel matrix of the mode 
13h display. In fact, we could use Bresenham’s algorithm to track a ray from maze 
square to maze square, just as we used it in chapter 2 to draw straight lines made 
up of pixels. 

This would be a fast and efficient way to track rays emanating from the 
players position across the grid of maze squares, but it isnt accurate enough for 
our purposes. Ir would tell us if the ray encountered a wall: it would even tell us 
which wall of which maze square the ray encountered. But it wouldnt tell us the 
precise point on the wall that the ray encountered. As youll see later in this 
chapter, we need that information to determine just how to draw the wall. 

The problem lies in the coordinate system that were using to describe the 
maze grid. It isnt fine enough. We need a coordinate system that will not only 
allow us to specify maze cube positions throughout the maze grid, but that 
will allow us to identify specific positions within a maze cube, 

To solve this problem, we're going to introduce a second coordinate system 
that we will use when we need more specthc information about the path of a ray. 
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Figure 9-3 The fine coordinate system is nested inside the maze grid, with 64 by 64 
coordinates inside each grid square 


We'll call this second coordinate system the fine coordinate system. So that there 
wont be any confusion about these coordinate systems, well continue referring 
to the original coordinate system as the maze grid. 


The Fine Coordinate System 


The fine coordinate system will be nested inside the maze grid, as shown in 
Figure 9-3. Each square of the maze grid will in turn contain a 64 by 64 portion 
of the fine coordinate system. We havent chosen this size arbitrarily. The fact that 
64 is a power of 2 will simplify some of the calculations when we optimize the 
ray-casting engine in chapter 12, And later in this chapter we'll be using 64 by 64 
bitmaps to map textures onto the walls of the maze cubes. The fact that the pixel 
matrix of these bitmaps is identical to the ne coordinate system within the maze 
cubes will simplify the texture mapping considerably. 

In the code that we develop in this chapter, well use this fine coordinate 
system in two different ways: to represent positions within a single grid square, 
and to represent positions within the maze as a whole, Ac times, we'll specify the 
position of a poine within a grid square by stating that the point falls at 
coordinates frae_x and five_y within the grid square, with the coordinates grid_x 
and grid_y. At other times, well specify the position of a point within the fine 
coordinate system of the entire maze, The difference between these two methods 
of specifying a position should be obvious from context. 

Up until now, we've been using maze grids that have measured 16 by 16 — 
that is, there have been 16 maze squares in each of 16 rows of maze squares, for a 
total of 256 maze squares, each of which might or might not contain a maze 





CHAPTER NINE Ray Casting 


cube. We'll continue using grids of this size throughout the rest of this book, 
though the techniques that I'll be describing will work with mazes of other 
dimensions. (In some cases, the techniques will assume that the maze dimensions 
correspond to powers of 2.) However, the fine coordinate system nested within 
all of these squares will measure 64 x 16 by 64 x 16 — or 1024 by 1024. That 
means there will be a total of more than 1 million fine coordinate points within 
each maze! Keeping track of all these points is not as difficult as you might think. 

Fram time to time, well need to translate back and forth between the fine 
coordinate system and the maze grid coordinate system. [his is actually a simple 
thing to do. To discover which grid square contains a given pair of x,y 
coordinates in the fine coordinate system, we'll divide the fine coordinates by 64, 


like this: 


grid_x = fine_x / 64; 
grid_y = fine_y / 64; 


Because we ve had the foresight to use a power of 2 here, this can, if necessary, be 
rewritten as a shift operation, which is often faster than a division: 


grid_x = fine_x >> 6; 
grid_y = fine_y => 4; 


To find the coordinates of these nwo points imside the erid square at grid_x, 
grid_y, we can take the values of fine_xfine_y modulo 64 (that is, the remainder 
after these values have been divided by 64), like this: 


inside _x = fine_x & 64 
inside_y = fine_y 4 64 


The modulus operation takes as long as a division. Since we've used a power of 
2, we can also obtain the value of these numbers modulo 64 by ANDing them 
with 63 (hexadecimal 0x36}: 


inside _x = fine_x & Oxf 
inside_y = Tine_y & Ox3f 


We can translate coordinates in the other direction as well. IF we know that a 
given point is at coordinates fime_x,fime_y within grid square grid_x,grid_y, we can 
determine the fine coordinates of the point within the entire maze like this: 


il 


mMaze_x 
maze ¥ 


grid_x * 64 + fine_x; 
grid_y * 64 + fine_y: 


il 


where maze_x and maze_y are the fine coordinates within the maze as a whole. 
We can also rewrite these two instructions using shifts: 


maze = grid_x << 6 + fine_x; 
Maze_y = grid_y << 6 + fine_y; 
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Rays Within the Grid 


When we cast a ray from the viewers position into the maze, we'll use the fine 
coordinate system to trace its path. Thus we'll not only know if the ray strikes a 
wall, but where on the wall it strikes, (Well, we won't know exactly where it 
strikes, but we'll know within a tolerance of 1/64th of the length of the wall, 
which is close enough.) 

If we were writing a full-featured ray tracer, we would need to compare each 
ray with every cube in the scene to see if it encountered a wall. But our maze 
representation only allows walls to occur along the edges of a grid square. So we 
only have to check for ray-wall collisions along those edges. As we trace the ray, 
we can think of the lines of the maze grid as corresponding to lines in the fine 
coordinate grid that are evenly divisible by 64. Since walls can only occur at these 
paints in the grid, we need only check for collisions between the ray and lines in 
the fine coordinate grid that are divisible by 64. We'll refer to these lines as grid 
lines. Those chat run parallel to the x axis we'll call x grid fines, and those that run 
parallel to the y axis we'll call y era lines, 

A ray of light, as we saw in the last chapter, can be treated as a straight line. In 
chapter 5, when we introduced code to clip polygons on a display, we saw that 
the pont where ck straight line CIrOSSes. a second line that 1 [Ss parallel to) either the XK 
OT ¥ LCS of the coordinate System could be calculated using the point-slope 
equation. The grid lines in our maze array are all parallel to either the x or the y 
axes of the mazé coordinate system — either the fine coordinate system or the 
maze grid coordinate system — so we can use the point-slope equation to 
determine where the ray crosses a grid line. The point-slope equation requires 
chat we first calculate the slope of the ray: 


slope = (y2 - yl)/€x2 - x7) 


where x/,y/J and x2 “2 are the coordinates of pwo points along the ray, with xJ,p/ 
being closer to the viewer than x2,y2. These points can belong to either the fine 
coordinate system or the maze grid coordinate system, though we'll be using the 
hne coordinate system because of its greater accuracy. 

Once we've calculated the slope of the ray, we can determine the x,y 
coordinates at which the ray crosses a grid line running parallel to the y axis with 
this formula: 

x = grid.x; 

y = yl * slope * (grid_x - =1); 

where gried_x is the x coordinate of the grid line. (Since the grid line is running 
parallel to the y axis of the coordinate system, the x coordinate will be the same at 
any point on the line.) 
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Figure 9-4 Standing at fine coordinates 
42,32 within the maze grid square with 
coordinates 8,8, ooking north 


We can similarly use the potnt-slope equation to calculate the x,y coordinates 
at which the ray crosses a grid line running parallel to the x axis, like this: 


x1 + (grid _y —- yl?) / slope; 
grid_ y; 


x 


The Basic Ray-Casting Algorithm 


To see how this will work, imagine that you are standing at fine coordinates 
32,32 within the maze grid square at grid coordinates 8,8, looking due north 
through the maze (see Figure 9-4). And suppose we want to follow a ray precisely 
in the center of your field of vision to see if it encounters a wall. First well need 
to derive the fine coordinates within the maze as a whole at which the ray starts. 
We can do this using the formula for translating from fine coordinates within a 
erid square to fine coordinates within the maze as a whole: 

xT 
yi 


gridx * 64 + fine_x; 
grid_y * 64 + fine_y; 


i 


where xl and yl are the fine coordinates at which the ray begins. When we 
perform this operation on the ray in Figure 9-4, we get starting coordinates of 
344,544. 

To calculate the slope of the ray, we'll also need the coordinates of a second 
point further along the ray. We'll arbitrarily use the point that is 1,024 coordinate 
units distant from the start of the ray. Since the ray is heading straight north 
(which well define as parallel to the y axis of the coordinate system in the 


303, 
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positive y direction), this point will have the same x coordinate as the starting 
point of the ray, with a y coordinate 1,024 units greater: 


x2 = x1; 
ye = ¥1+1024; 


For the ray in Figure 9-4, this gives us the coordinates 44,1568. 
Now we can calculate the slope of the ray: 


slope = (y2 — y1}/(x2 - x1); 


It may occur to you that if «2 and x/ are the same number, which would be the 
case if the ray were perfectly vertical (or, in the case of our rays that we'll be 
casting through the maze, heading due north), this formula will penerate a 
divide-by-O error. That's a problem with the point-slope equation and with the 
general mathematical concept of slopes. Mathematicians declare the slope of a 
vertical line to be infinite, bur its difficult to deal with infhinities in C++ (or in 
any computer language, for that matter). So we'll solve this problem by cheating, 
as you ll see in a moment. 

With that information in hand, we can begin determining whether the ray 
encounters a wall at some point along its path. Since walls only occur at grid 
lines, we need to find the next grid line that the ray will cross. Grid lines, you'll 
recall, are those lines running parallel to the axes of the fine coordinate system 
that have either an x or a y coordinate that is evenly divisible by 64. The easiest 
way to determine where the next grid line is would be to find the previous grid 
line (thar is, the one that the ray would have crossed last if it extended from 
behind the viewer) and add 64 to its x or y coordinate. Bur how do we find the x 
or y coordinate of the previous grid line? We can find the y coordinate of the last 
x grid line that the ray would have passed through by taking the y coordinate of 
the Start ot the ray and finding the largest number noc exceeding that coordinate 
that was evenly divisible by 64. Since the y coordinate will be stored in the 
computers memory as a binary number, we can do this by simply setting the last 
six binary digits of the number to 0, which is a matter of ANDing the number 
with hexadecimal FFCO. Similarly, we can find the x coordinate of the last y grid 
line crossed by the ray by ANDing the current y coordinate with FFCO. 

The ray in Figure 9-4 is heading due north, so it never actually crosses any y 
coordinate lines (the ones that are parallel to the y axis), since the ray is itself 
parallel to the y axis. The next x grid line that it crosses has a y coordinate of 578. 
We can easily calculate this using the formula we just described: 


grid_x = (x1 && OxffcO) + 44; 


We can then find the intersection of the ray with this line using the point 
slope equation. If the intersection of the ray and the line occurs at fine 
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coordinates xcross,ycress, we can easily translate these coordinates into maze grid 
coordinates like this: 


int xmaze = xcross/64; 
int ymaze = ycross/64; 


Determining whether the ray has struck a wall then becomes a matter of 
checking the maze array to see if there's a maze cube at those coordinates: 


if (mapCxmazellymazel]) { 


If there is, we then calculate the distance to the wall and draw a vertical 
segment of the wall in the viewport column position that corresponds to the ray 
being traced. More about drawing the wall in a moment. 

If there isnt a wall at this point, we must cast the ray again from the point of 
its intersection with the grid line, repeating this process until a wall is 
encountered or we reach a preset limit to our ray casting. 


Rays in All Directions 


Nort all rays that we cast will head due north, of course. If the ray had been 
heading due east (in the positive y direction parallel to the x axis), it would 
intersect the y grid line at 374 rather than the x grid line at 974 (see Figure 9-5). 
This can also be handled by the algorithm [ just described. If the ray heads in the 
negative direction on the x or y axis, we ll need to look for intersections with the 
previous grid line rather than the next grid line (see Figure 9-G), Although this 
might sound like a simple matter of ANDing the current ray coordinates with 
OxttcO and wer adding 64 to it, the situation is actually a bit more complicated 
than that, When we divide the resulting coordinates by 64 to derive the maze 
grid coordinates, we would end up with the coordinates of the square where the 
ray started rather than the coordinates of the Next square it encountered. Thus Wit 
must subtract | from the x or y coordinate of the x or y grid line to nudge the 
coordinates into the proper square. This will put us one coordinate off from the 
actual grid line, but this actually won't cause any problems. The calculation for 
the next x grid line in the negative direction will look like this: 


grid_x = (xl && Oxtfell) <1; 


The next y grid line can be found in a similar manner. 

In practice, we will rarely be dealing with a ray that heads due north, south, 
east, or west, Most of the rays that we cast wont be parallel with either the x or y 
axes of the coordinate system. Thus they will cross both x and y grid lines. To 
determine whether the ray next crosses an x or y grid line, we must determine its 
Intersection with Poth the next x and the next y grid line, determine the distance 
to each, and check to see which is closer to the current ray coordinates, Thar will 
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Figure 9-5 4 ray heading east intersects Figure 9-6 Rays heading in the negative 
the y arid line at coordinate 574 x and y direction will strike the next 
lowest numbered grid line 


then become the next point of intersection and we'll check to see if there's a wall 
at that location. 


The Wallcasting draw_maze() Function 


Now were ready to create a ray-casting version of our familiar draw_maze() 
function. Our first version will cast for walls only and will draw those walls in a 
solid color. Later in this chapter, we ll add texture mapping and Hoorcasting 
capabilities to the function. We'll place the first version of this function in the file 
WALLCAST.CPP 
The prototype for the function, which well place in the hle WALLCAST.H, 
looks like this: 
void draw_maze(map_type map,char far *screen,int xview, 
int yview,float viewing_angLe, 
int viewer_height) 
The frst parameter is an array of map_type, which will be defined in 
WALLCAST-H like this: 
typedef int map_typelT6J(16]; 


This 16 by 16 array will hold a maze grid of the sort we described earlier, in 
which each element represents a maze square. Non-zero elements mean that 
there's a maze cube in the equivalent maze location, zero elements that theres 
only empry space. 

The sereen parameter is a pointer to video memory or to an off-screen image 
bufter, The integer variables xevew and yriew are the fine coordinates at which the 
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0 Rodians (North) 


4.71 Rodions (West) 
(}s03) suoipoy /"| 





3.14 Rogians (South) 
Figure 9-7 An angle of 015 due north. All 


other angles aré measured relative to this 
angle 


viewer is standing within the maze as a whole. And the Hoating point variable 
wewing_angle is the angle, in radians, at which the viewer is currently facing, 
where an angle of 0 is due north. Figure 9-7 shows a “compass with the 
approximate radian equivalents for the four cardinal directions and an example of 
an arbitrary radian direction. (Its impossible to give the exact radian equivalents 
for the cardinal directions, since radians are based on pi and the equivalent values 
for 90, 180, and 270 degrees would each have an infinite number of digits after 
the decimal point.) The eiewer_beight parameter is the desired height of the 
viewers eye level above the maze oor, measured in pixels. Since the walls in the 
maze will be 64 pixels high, we'll generally want to set this value to 32, putting 
the viewers eye-level halfway between floor and ceiling. However, other values 
can be used to create Interesting effects, such as crouching, leaping, and standing 
on top of an object. Values of less than 0 or greater than 63 arent recommended, 
since they allow the viewer to see over the top of the walls (revealing holes in the 
scenery). 

We'll place some useful constant definitions at the head of the 


WALLCAST.CPP fle: 

const WALL_HEIGHT=64; ‘/ Height of wall in pixels 
const VIEWER _HEIGHT=32; ff Viewer's eye lLewel in pixels 
const VIEWER_DISTANCE=128; ff Viewer distance from screen 
const VIEWPORT_LEFT=40; ‘/ Dimensions of viewport 


const VIEWPORT_RIGHT=280; 
const VIEWPORT_TOP=50; 
const VIEWPORT_BOT=150; 
const VIEWPORT_HEIGHT=100; 
const VIEWPORT _CENTER=100; 
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And well declare some necessary variables at the beginning of the function: 


int sy,otfset; ‘/ Pixel y position and offset 
float xd,yd; ‘/ Distance to next wall in = and y 
int bound _x,bound_ ¥; ‘/ Coordinates of x and y grid Lines 


float xcross_x,xcross_ y; // Ray intersection coordinates 
float ycross_x,ycross_ y; 


int xdist,ydist; ‘/ Distance to x and y grid Lines 
int xmaze,ymaze> ‘/ Map Location of ray collision 
int distance; ‘/ Distance to wall along ray 


We'll see what each of these constants and variables does in the course of the 
function. 


stepping Through the Columns 


The function itself is structured as one large for() loop, which will step through 
all of the vertical columns af pixels from the left side of the viewport to the riehe: 


for (int columm=VIEWPORT_LEFT; column=VIEWPORT_RIGHT; column++) f 


This is where things start getting interesting. In order to cast a ray through 
each column of pixels, we need to know the angle at which the ray ts traveling 
relative to due north (which will have an angle of 0 radians). The viewer is facing 
at the angle contained in the Hoating point parameter viewrng_angle, so lets first 
calculate the angle relative to this angle. [o do this well need to use a little 
trigonometry. Figure 9-8 shows the viewer looking at the video display, as seen 
from above, There are two lines extending from the viewers eyes to the screen: 
Line A represents the straight line distance to the screen (which is contained in 
the constanr VIEWER DISTANCE), and line C extends from the viewer to an 
arbitrary column of pixels on the screen. Line A intersects the display directly in 
the middle, at pixel column 160 on the mode 13h screen. Line C intersects the 
display at the pixel column contained in integer variable column, the index 
variable for the fer(/ loop that we just initialized, 


A Touch of Trig 


You'll notice that these nwo lines, combined with the straight surface of the video 
display, form a triangle. We know three things about this triangle. We know that 
the side labeled A ts VIEWER_DISTANCE in length, we know that the side 
labeled B is column-/60 in length, and we know that the angle berween side A 
and side B is a right angle — that is, thar it measures 90 degrees (or pi/2 radians). 
What we need to know ts the column angle — that is, the angle between sides A 
and C. There's a simple trigonometric equation that will give us this angle: The 
angle between A and C equals the aretangent of the length of side B divided by 
the length of side A, We can easily express this in C/C++, like this: 
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Figure 9-8 4 viewer looking at the video display. Line A 
represents the straight-line distance to the screen and 
Line € the distance to the column through which the ray 
i$ Cast, Note that these two lines forma tnangle with the 
screen (Line B) 


float column_angle=atan( (float) (column-160) 
/ VIEWER_DISTANCE); 


Now we need to find the absolute angle of the ray on the radian compass thar 
I showed you back in Figure 9-7, where 0 radians represents due north. Since we 
know the angle between the center of the viewers vision and the ray to the screen 


column, we can find the absolute angle by adding the column angle to the angle 


of the center ray, which was passed to the draw_maze() function in the parameter 
viewing_angle: 
float radians=viewing angle+coLumn_angle; 


The absolute angle of the ray passing through the column is now contained in 
the Hoating point variable radians. 


Rotating the Ray 


In order to compare the ray against the grid lines to see if it encounters a wall, we 
need to know the fine coordinates of two points on the ray, We already know the 
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Imaginary ray at angle of O rodions 












*" Translation to actual viewer posi 
Gt coordinates XVIEW, YVIEW 





Actual viewer position ot XVIEW.YVIEW 


Figure 9-9 Rotating and translating an imaginary ray to 
the viewing angle and view position 


fine coordinates of the start of the ray: They are contained in the integer 
parameters xevew,yutew. But we also need another pair of coordinates from some 
point further along the length of the ray. Earlier, when we were dealing with a ray 
that headed due north from the viewer, we simply added 1,024 to the y 
coordinate at which the ray started. But that only works with a ray traveling at an 
angle of 0 radians. This ray could be traveling at any possible angle. How do we 
find a second point along its length? 

The answer is thar we can use the two-dimensional rotation equation that we 
introduced in chapter 7. This equation allowed us to rotate a point by an 
arbitrary number of radians around the 0),0 origin point of a Cartesian coordinate 
system. As illustrated in Figure 9-9, we'll start with an imaginary line that extends 
from 0,0 to 0,1024; rotate the second set of coordinates around the first by 
radians; and translate the point relative to the viewer's actual position by adding 
xview,yvieu' to the coordinates. (Translation, youll remember, is the act of 
moving a set of coordinates by a given x,y offset to another point in the 
coordinate system.) This will give us the starting and ending points of a 1,024- 
pixel-long segment of the actual ray. 

To refresh your memory, the two-dimensional rotation equation looks like 
this: 
rotated x 
rotated _y¥ 


old_x * costangle) - old_y * sintangle) 
old_y * cos(angle) = old_x ® sinlangle) 
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The old_x and old_y values here correspond to the x,y coordinates of the 
endpoint of our imaginary line, which are 0.1024. When we plug those into the 
equation, we get: 


rotated_x = 0 * cos(angle) - 1024 * sinlangle? 
rotated_y = 1024 * costangle) - 0 * sinfangle) 


Any number multiplied by 0 equals 0, so we can eliminate the terms in this 
equation that contain 0 factors without affecting the results: 


ii 


rotated x 
rotated_y 


1024 * sintangle) 
1024 * costangle) 


If we wanted, we could even replace the multiplication with a shift, since we ve 
chosen to multiply by a power of two, But we're not writing optimized code at 
the moment, so well go ahead and use the multiplication in our C++ code for 
clarity's sake: | 


int x2 = 1024 * Ceos(radians)); 
int y2 = 1024 * Csintradians)); 


To translate these coordinates to their proper position relative to the viewer, 
we merely add the viewers coordinates to them: 


XEOT=EVIEW! 
yet=y¥vViewW; 


Casting the Ray 

Now we need to start casting the ray. We'll use a pair of Hoating point variables, x 
and 4 to hold the coordinates of the ray as we cast and recast it. Initially, these 
will be set equal to the starting position of the ray, but as we recast the ray from 
the points at which it intersects the grid lines, well update these variables to the 
coordinates of the intersection: 


float x=xview; 
Tloat y=yview; 


Were using floating point variables here because we must maintain the precise 
position at which the ray intersects the grid lines. The fine coordinate system 
actually isn't fine enough for this purpose; fractional errors would accumulate in 
the ray coordinates Over the COLPSe ot several ChnCOUNTCES, rendering CLT results 
inaccurate. This would in turn throw off our calculation of the wall heights, 
causing odd little “spikes” to appear at the tops and bottoms of the walls. If youre 
curious about this problem, you can try recompiling this code using integer 
variables. 

(An alternate solution to the problem would be to use an even finer coordinate 
system nested inside the fine coordinate system, though we would need to use 
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long integer variables to maintain the ray coordinates in such a system. Yet 
another alternative, which we'll look at more closely in chapter 12, is to use so- 
called fixed point math to maintain the coordinate positions. Interestingly 
enough, these two alternatives would result in almost identical code. Because 
they re essentially identical, these two methods would be equally fast — and both 
would be much faster than the Hoating point code that we're using here.) 


The Slope of the Ray 


The first step in determining where the ray intersects the grid lines is to find the 
slope of the ray. Well break this operation into several steps, first determining the 
difference in the x and y coordinates from one end of the ray to the other, and 


storing these values 1 Nn the variables xaiff and yatth 


int xdiff=x2<-xview; 
int ydift=ye-yview; 


To determine the slope, we must divide ydiff by xaiff If xeiff is equal to 0 — 
meaning that the slope of the line ts effectively infinite — this will cause a divide- 
by-0 error, so well need to watch for this condition and take appropriate action if 
it occurs. We could treat infinite slope as a special case and handle it with special 
routines, but that’s too much of a bother. Instead, we ll cheat: 


if (xdiff==0) xdiff=1; 


This way, xf will never be equal to 0 and the problem will never occur. OF 
course, this means that we'll never have a ray thats perfectly vertical, but in 
practice this will scarcely be noticeable. 

Now We Can obtain the slope of the ry. 


float slope = (float)ydiff/xdiff; 


Notice that we force the result of the division to floating point by using a float 
cast on the variable yale Otherwise, the result of the division would be an 
integer and any fractional portion would be truncated before being assigned to 
the Hoating point variable slope. 

We'll be using slope later as a divisor, so we must cheat a second time to avoid a 
divide-by-0 error: 


if (slope==0.0) sltope=.0001; 
Because slope is a Hoating point variable, we can cheat in a more subtle manner 


than we did with the integer variable xdi/f} using a very small fraction to 
represent 0 slope. The result should be unnoticeable. 
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Casting ina Loop 

We'll perform the actual ray casting in a loop. Because we dont know when the 
loop will end — it will be terminated whenever a wall is found — we'll use an 
infinite for’) loop which we can break out of when our work is complete: 

for (77) ¢ 


We could also use a while() loop for this purpose, checking on each iteration to 
see if weve plumbed the depths of the maze up to some predefined limit. 
However, this would slow down execution somewhat, and isnt strictly necessary 
if Wit design the Maze 50 that the ray will always C€NnCOUNTEr a wall, Be warned, 
though, that if the ray is allowed to pass through the side of the maze and escape 
— thar is, if we fail to surround the perimeter of the maze with solid cubes — 
this loop will either become infinite or will crash resoundingly. 

To find the first collision between the ray and an x grid line, we must 
determine if the ray is traveling in the positive or negative x direction — that is, 
toward larger or smaller x coordinate values. This is easy enough to do: If the 
value of xaiff is positive, then the ray is traveling in the positive direction; if xdZ/f 
Is negative, the ray 1s traveling in the negative direction. If we're traveling in the 
positive direction, well use the formula x & (fic) + 64 to find the next x grid 
line: 


if (xdiff>0) grid_x=(Cintix & OxtfcO)+64; 


If the ray is traveling in the negative direction, well use the formula 
x & offeO - 1 vo find the previous x grid line minus 1: 
else grid _x=(Cint)x & OxffcO) - 1; 


We'll repeat this process to find the next (or previous) y grid line: 


if Cydiff>0) grid_y=(Cintiy & OxffeO) +64; 
else grid_y=((intiy & OxffcO) = 1; 


Calculating the Point of Intersection 


The next step is to use the point-slope equation to find the x,y coordinates where 
the ray crosses the x and y grid lines, We'll use the floating point variables xerass_x 
and xcrass_y to hold the coordinates at which the ray crosses the x grid line, and 
the floating point variables yeross_x and yeress_y to hold the coordinates at which 
the ray crosses the y grid line: 

KCrOSSs x=grid_x; 

xCross  y=y+slope*(grid_x-x); 


yeross x=x+(grid_ y-y)/slope; 
¥cross  y=grid_ y; 
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Before we can check for the presence of a maze cube, we need to know which 
of these grid lines the ray strikes first, We'll use the Pythagorean method — 
adding the squares of the x and y distances to get the straight line distance — for 
calculating the distance to the x grid line: 
xd=xcross_x-x; 


¥d=xcross y-¥; 
ndist=sort(xd*xd+yd* yd) > 


And well use the same method for finding the distance to the y grid line: 


xd=yeross_x-x; 
¥YO=yCross_y¥“¥; 
ydist=sqrt(xd*xdt+yd* yd); 


What we do next depends on which ray is shorter — the one to the x grid line or 
the one to the y grid line. First we check to see if the x grid line is closer than the 
¥ grid line: 

if <xdist<ydist) 


lf it is, then we calculate the maze grid coordinates of the maze square that is 
aligned at that point with the grid line: 
uMaze=xcross_x/64; 
yMaze=xcross_y/64; 

If there is no maze cube here and we need to start casting again, we must reset 
the variables » and y to the coordinates at which the ray intersected the line: 


Z=KCPOSS x; 
y=excross y; 


Even if there is a maze cube art this position, well need these coordinates to 
determine the distance from the viewer to the point of collision. 
Finally, we check to see if there's a maze cube at this position. If so, we break 
out of the fort) loop: 
if (mapCxmazellymazel]) break; 
} 
lf the ray to the y grid line is shorter than the ray to the x grid line, we perform 
the same set of operations on the point of collision with that grid line: 
else { 
xmaze=yeross_x/64>5 
ymaze=ycross_y/G4; 
x=Yoross_x; 


y=ycross__ ¥; 
if (maplCxmazellymazel) break; 
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Drawing the Wall 


If the program reaches this point, a cube has been found in the maze square with 
maze eprid coordinates xmaze,ymaze. The point of collision between the ray and 
the maze is at coordinates xy. To find the distance from the viewer to the point 
of collision, we must subtract the viewers coordinates from the collision 
coordinates and apply the Pythagorean distance calculation: 

xd=x-xV1eW; 


¥d=y-yview; 
distance=(Long)sqrt(xd*xd+yd*yd)*cos(column_angle}; 


Youll notice that we multiply the distance to the wall by the cosine of the angle 
berween the center of the viewers vision and the column through which we've cast 
the ray. (We earlier stored this angle, in radians, in the variable colwmn_angie.) 
This avoids a “hsh-eye" effect in the final image. Figure 9-10 shows why this is so. 
As the column through which the ray is being cast moves further away from the 
center of vision, the rays become longer and longer (all other things being equal) 
and the otherwise straight walls will seem to grow shorter and shorter as they 
extend outward to each side. This is not, however, the way that the walls would 





Figure 9-10 The rays grow longer as they move outward 
from the center of the screen 
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appear to our eyes. Multiplying the distance by the cosine of the angle provides 
precisely the adjustment needed to make the walls seem straight and true. 

A distance of (), which can occur if the viewer is smack-dab up against the 
wall, will cause problems in subsequent calculations, so we cheat once again to 
avoid the problem: 


if (distance==0) distance=1; 


Now we need to know the visible height of the wall, so char we can draw it in the 
appropriate position in the viewport. We can use the method that we introduced 
back in chapter 7 for calculating perspective. That method converted the x,y 
coordinates of a point in space into screen coordinates by dividing them by the z 
coordinates of the point (which had been previously multiplied by a factor 
representing the viewers distance from the screen). We can also use this 
perspective formula to adjust the wall height, like this: 


int height = VIEWER DISTANCE * WALL_HEIGHT / distance; 


The integer variable Feight now contains the number of visible pixels that are 
needed to represent the height of the wall in the current screen column, In order 
to draw this portion of the wall | In a soli d color, Wwe merely need tO draw 
cl column of pixels that tall (Th the screen In the appropriate position in 
the viewport. But in order to do that, we need to know at which screen positions 
the top and bottom pixels on the column will fall. (We could get by with only 
the top position, but knowing the bottom position simplifies the clipping of the 
wall column against the top and bottom of the viewport. Later, when we add 
bitmapped Hoors to our ray-casting system, we'll need to know where the bottom 
of the wall is so we can stop drawing the floor when we come to it.) 

First well calculate the position of the bottommost pixel. If we assume that 
the viewers eye level is fixed at a vertical point on the screen defined by the 
constant VIEWPORT _CENTER (which we've set equal to position 100, 
directly in the middle of the mode 13h display), then the Hoor will be ar a 
distance of viewer height below this point. (Youll recall that viewer_Aeight is the 
height of the viewer's eye level relative to the floor of the maze, measured in 
pixels.) We can adjust vrewer_hetght with the perspective equation to get the 
visible position of the bottom of the wall relative to the center of the viewport, 
then add VIEWPORT_CENTER to this value to get the equivalent position on 
the display: 
int bot = VIEWER_DISTANCE * VIEWER_HEIGHT 

/ distance + VIEWPORT_CENTER; 
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The variable fet now contains the y coordinate of the bottom of the wall on 
the display. To get the ¥ coordinate of the top of the wall, we add height to this 
heure: 


int top = bot -— height; 


Before we can draw this line, we must clip it to the top and bottom of the 
viewport. If top is less than VIEWPORT_TOP — thar is, if the column extends 
above the top of the viewport — we'll subtract the difference between 
VIEWPORT _TOP and tap from height and set top equal to VIEWPORT TOP: 
if (top < VIEWPORT_TOP) f 

height -= (VIEWPORT_TOP - top); 


top = VIEWPORT_TOP; 
} 


If bor is greater than VIEWPORT_BOT — thar is, if the column extends 
below the bottom of the viewport — well subtract the difference berween bor 
and VIEWPORT_BOT trom fete. (It's not necessary to adjust the value of bor, 
since we wont be using it again.) 

The video memory offset of the top pixel in the wall column can be calculated 
using the standard formula that we've used throughout this book, with top 
representing the y coordinate of the pixel and cofwmn (which contains the 
horizontal position of the current viewport column on the display) representing 
the x coordinate: 


offset = top * 320 + column; 


Finally, well use a fer() loop to draw the column, setting the video memory 
location of the pixel at effrer to 15 (for the color white) and incrementing the 
offset position by 320 on each iteration of the loop: 

for Cint 1=0; i<heitght; i++) f 
screenLoffsetJ=15; 
offset+=320; 

} 


} 
} 


And that’s all there is to drawing solid-colored walls using ray-casting 
techniques. The process that we ve LIST described 1s repeated for Cvery column of 
pixels in the viewport, building up a solid-colored rendition of the walls that lie 
in the viewers line of sight. The complete drzw_maze() function, along with 
related #rmcludes and constant declarations, appears in Listing 9-1. 
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The draw_maze() Function 





tai Listing 9-1 The wallcasting draw_mazel) function 


‘ff WALLCAST.CPP 


‘/ Function to draw solid=-colored walls using ray casting. 
{/ Written by Christopher Lampton for 
‘/ Gardens of Imagination (Waite Group Press). 


Finclude <stdio.h> 
Finclude <math.h> 
Ainclude “raycast.h" 
#include "pex.h" 
Hinclude "“distance.h" 
Finclude “slope.h" 


‘// Constant definitions: 


const WALL HEIGHT=64; /*f Height of wall in pixels 
const VIEWER_HEIGHT=32; ff Viewer's eye Level in pixels 
const VIEWER_DISTANCE=128; ‘/ Viewer distance from screen 
const VIEWPORT_LEFT=40; ‘/ Dimensions of viewport 


const VIEWPORT_RIGHT=280; 
const VIEWPORT_TOP=50; 
const VIEWPORT_BOT=150; 
const VIEWPORT_HEIGHT=100; 
const VIEWPORT_CENTER=100; 


extern pcx_struct bitmap; 


void draw _maze(map type map,char far *screen,int xview, 
int yview,float viewing_angle? 


‘/ Draws a raycast image in the viewport of the maze represented 
f/f in array MAPCJ, as seen from position AVIEW, YVIEW by a 

// wiewer Looking at angle VIEWING_ANGLE where angle 0 is due 

‘/ north. (Angles are measured in radians.) 


{ 
‘/ Variable declarations: 


int sy,offset; ff Pixel y position and offset 

float xd,yd; ‘/ Distance to mext wall in x and y¥ 
int grid_x,grid_y; // Coordinates of x and y grid Lines 
float xcross_x,xcross yy; // Ray intersection coordinates 
float yeross_“,ycross_y; 
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int xdist,ydist; // Distance to x and y grid Lines 
int xmaze,ymaze; ‘/ Map Location of ray collision 
int distance; // Distance to wall along ray 


ff ***The raycasting begins: 


// Loop through all columns of pixels in viewport: 
for Cint column=VIEWPORT_LEFT; column<VIEWPORT RIGHT; columnt+) 7 


// Calculate horizontal angle of ray relative to 
ff center ray: 
float column_angle=atan( (float) (columm=-160) 

/ WVIEWER_DISTANCE); 


‘f Calculate angle of ray relative to maze coordinates 
float radians=viewing_angle+column_angle; 


‘i Rotate endpoint of ray to viewing angle: 
int x2 = 1024 * (cos(radians)); 
int yé = 1024 * (sintradians))}; 


f/ Translate relative to viewer's position: 
net=xXVIeW 
¥et=¥view 


‘i Initialize ray at viewer's position: 
float x=xview; 
float y=yview; 


ff Find difference in x,¥ coordinates along ray: 
int xdiff=x2=-xvieu; 


int ydifft=y2-yview; 


// Cheat to avoid divide-by=-zero error: 
if (xdiff==0) xdiff=1; 


‘i! Get slope of ray: 
float slope = (float)ydift/xdifft; 


/‘/ Cheat (again) to avoid divide-by-zero error: 
if (slope==0.0) slope=.0001; 


ff Cast ray from grid Line to grid Line: 
for (::) 4 


ff If ray direction positive in =, get next x grid Line: 
if (xdiff>0) grid _x=(Cint)x & OxffcO)+é64; 


ff If ray direction negative in =, get Last x grid line: 
else grid_x=((Cint)x & OxffcO) - 1; 


ff If ray direction positive in y, get next y grid Line: 
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continued from previous pater 


} 


if (ydiff>O) grid_y=(Cintdy & OxffcO) +64; 


‘f If ray direction negative in y, get Last y grid Line: 
else grid y=((int)y & OxffcO) = 1; 


// Get x,y coordinates where ray crosses x grid Line: 
xCross x=grid_x; 
xcross y=yt+tslope*(orid_x-x): 


// Get x,¥ coordinates where ray crosses y grid Line: 
ycross_x=x+(grid_y-y)/slope; 
¥ycross y=grid_y; 


// Get distance to x grid Line: 
xd=xcross_x-x; 

yd=xcross_y-y; 
ndist=sqrtixd*xd+yd* yd) ; 


// Get distance to y grid Line: 
xd=ycross x-x; 

¥d=ycross y-¥; 
ydist=sgrt(xd*xd+yd*yd) ; 


ff If x grid line 15 closer... 


1f (xdist<ydist) ¢ 


/* Calculate maze grid coordinates of square: 
amare=xeross x/64; 
ymaze=xeross_ ¥/64; 


// Set x and y to point of ray intersection: 
w=xCcross x; 
Y=xCcross_y; 


/f Is there a maze cube here? If so, stop Looping: 
if (maplxmazellymazel) break; 

} 

else { // If y grid line is closer: 


ff Calculate maze grid coordinates of square: 
smaze=ycross_x/é4; 
ymaze=yeross_y/64; 


ff Set x and y to point of ray intersection: 
Z=YCPOSS_X; 
Y=¥Cross ¥; 


ff Is there a maze cube here? If so, stop Looping: 
if (mapCxmazellymazel) break; 


ff ***Prepare to draw wall column: 
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ff Get distance from viewer to intersection point: 
XO=xX—KVTEW; 

yd=y-yview; 
distance=(Long)sart(xd*xd+yd*yd)"*cos(column_angle); 
if (distance==0) distance=1; 


ff Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 


ff Calculate bottom of wall on screen: 
int Bot = VIEWER_DISTANCE * VIEWER_HEIGHT 
/ distance + VIEWPORT_CENTER; 


ff Calculate top of wall on screen: 
int top = bot — height; 


// Clip wall to viewport: 

if (top < VIEWPORT_TOP) f 
height -= (VIEWPORT_TOP - top); 
top = VIEWPORT_TOP; 

} 

if ({top + height) > VIEWPORT_BOT) { 
height -= (bot - VIEWPORT_BOT): 

} 


ff *®*0raw the wall column: 


ff Find video offset of top pixel in wall column: 
offset = top * 320 + column; 


// Loop through all pixels in wall column: 
for Cint j=0; isheight; i++) € 


ff Set wall pixels to white: 
screenLoffsetJ=15; 


f/f Advance to next vertical pixel: 
offset+=320; 


Tne WALLDEMO.CPP Program 


To show off the capabilities of this new version of the draw_maze() function, 


well write a short program that creates a maze array and calls dnaw_maze() to 
draw a ray-cast image of the maze, Much of the code in this program will be the 
same that weve used in earlier programs for setting the video mode, establishing 


al pointer iO video Memory, and S0 Of. There date a few ncw parts «LS well, 


Here's the declaration of the maze array: 


Rt 
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map type map=t 


ay By es ee Gee Ee ee es Fe fn Pt ff Fe Ss 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
i1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13, 
11,0,0,0,0,0,1,1,0,1,0,0,0,0,0,17, 
{1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,1,0,1,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,1,0,1,0,0,0,0,0,13, 
{1,0,0,0,0,0,0,1,0,0,0,0,0,0,0,17, 
M4 a 1. 


As noted earlier, zero elements correspond to empty sections of the maze, 
while Non-zZero elements correspond to Maze cubes. While it TLL SCC TH wastctul 
to devote an entire byte of data for a value that can only be zero or non-zero, 
we Il be using the full value of each byte later in this chapter. Note that, because 
of the way in which arrays are declared and because we have assumed that north 
is the positive y direction, the northern end of the maze is the lower part and the 
southern end ts the upper part, the reverse of the standard map convention. 

We'll declare a few variables up front to hold the viewing angle, the viewer's 
height, and the coordinates of the VICwer, though only the first ot these values 
will be changing in the remainder of the program: 
float viewing_angle=U; 
int viewer_height=42; 
int xview=8*64; 
int yview=8*64; 

In order to make this program slightly interactive, well allow the user to pass a 
command line value representing the viewing angle. Thus we'll need to use the 
arge and argv parameters in the declaration of the main() function: 
void main€int arge,char® argvLlJ) 


If there are no arguments on the command line, well default to a viewing 
angle of 0, which we've already declared. If arguments are detected, well convert 
them to floating point and assign them to the variable wewing_angle: 


if (arge==2) viewing_angle=atoffargvl11); 
We'll then proceed to set up mode 13h in the usual fashion. The call to the 
draw _mazet) function looks like this: 


draw maze(map,screen,xVview,y¥view,Viewing_angle,viewer_height); 
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This image will remain on the screen until the user presses a key. The full text 
of the program WALLDEMO.CPP appears in Listing 9-2. 





“tae Listing 9-2 The WALLDEMO.CPP program 


// WALLDEMO.CPP 

if 

/f Calls ray-casting function to draw mono-colored 
ff view of maze. 

ff 

/f Written by Christopher Lampton for 

ff Gardens of Imagination (Waite Group Press) 


Hinclude <stdio.h> 
Hinclude <dos.h> 
finclude <conio.h> 
Hinclude <stdlib.h> 
finclude <math.h> 
Finclude “sereen.h" 
Finclude "“pex.h" 
Finclude “wallcast.h" 


i 
mo, 


Map type Map 
{1,151 
{1,0, 
ti, 
ti, 
i 
Ly, 
{t, 
oe 
a 
ti, 
{1, F 
17 0, et ge lp 
ae Flat gp kl ge 


# 


ad 
i ra id Des 
0,0,0,0,0 
,0,0,0,0,0 
0,0,0,0,0, 
,0,0,0,0,0,! 
0,0,0,0,0, 
,0,0,0,0,0, 
0,0,0,0,0, 
,0,0,0,0,0,! 
,0,0,0,0,0 
0,0,0,0,1 
0,0,0,0,0, 
0,0,0,0,0 
,0,0,0,0,0 
,0,0,0,0,0 
plighp lel yl 


¥ 


ooo Pes Soba: 


¥ 


# 


float viewing_angle=0; 
int viewer_height=32; 
int xview=8"64; 
int yview=8*64; 


void mainCint argc,char® argvLJ) 
{ 


// Read arguments from command Line if present: | 
CH OF Bee pe er 
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if Cargce==2) viewing_angle=atofargvl11); 


‘/ Point variable at video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


‘/ Save previous video mode: 
int oldmode=*(int *IJMK_FPCOx460,0x49)> 


f/f Set mode 13h: 
setmodet(Ux13)> 


‘/ Clear the screen: 
cls(screen): 


‘/ Draw a raycast view of the maze: 
draw_maze(map,screen,xview,y¥view,viewing_angle,viewer height); 


if Wait for user to hit a key: 
while ('kbhitt)); 


‘/ Reset video mode and exit: 
setmode(oldmode) ; 


Running WALLDEMO.EXE 
To use this program, go to the RAYCAST directory and type WALLDEMOQ, A 


view of a solid-colored ray-cast maze, as viewed from a position at the center 
of the maze by a viewer turned to angle 0, will be drawn on the display (sce 
Figure 9-11). Press any key to return to DOS. To view the maze from other 
angles, type a Hoating point number on the command line following the program 
name. Remember thar the angle must be expressed in radians, so values should be 
in the range 0) to 6.28. Figure 9-12 shows the maze from an angle of 0.5 radians. 
Figure 9-13 shows the maze from an angle of 3 radians. 

Although the maze depicted by WALLDEMO is solid-colored, the results are 
still quite striking. Using a method quite different from any employed in 
previous chapters of this book, weve produced an image of the maze every bit as 
vivid as those produced by the polygon-based code in chapter 5. And yet at no 
point have we needed to deal with such issues as hidden-surtace removal or 
clipping polygons against the left and right edge of the viewport. (We still have to 
deal with the issue of clipping against the top edge of the viewport.) In fact, 
hidden surface removal is taken care of automatically and elegantly by the ray- 
casting procedure, because the rays will simply never strike hidden surfaces. And 
theres no reason to clip against the left and right edges of the viewport because 
we never cast any rays that go beyond these edges. 
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Furthermore, the fine coordinate system that we are using to specify the 
position of the viewer ts sufficiently high in resolution that we can potentially use 
this technique to create animations in which the movement is as smooth as that 
in a Hight simulator, which was our avowed goal at the beginning of this book. 
(This version of the ray-casting code really isnt fast enough to produce 
satistactory animation frame rates, but well develop an optimized version in 
chapter 12 that will run at considerably faster speeds.) 

Scull, the ray-cast image of the maze produced by this program isnt nearly as 
vivid as the bitmapped images introduced back in chapter 4. If all that we can do 
with ray casting is to create solid-colored images of a maze, the technique will be 
much too limited to creare maze games with, 

Fortunately, we can do a great deal more than this with ray casting, Lers add 


some more features to our draw maze() function, starting with texture mapping. 





Figure 9-17 A solid-colored ray-cast Figure 9-12 The same mare fram an 
view of The maze as produced by the angle of 0.5 radians 


WALLDEMO program 





Figure 9-73 _..and from an angle of 3 


ragians 
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Ray Casting and Texture Mapping 


‘Texture-mapping techniques, which allow us to cover the walls of the maze with 
scaled, bitmapped images, can easily be added to our ray-casting code. In fact, we 
already have almost all of the code that we'll need, Back in chapter 6, | 
demonstrated a technique for drawing a texture-mapped polygon as a series of 
vertical columns, where each column was scaled from the equivalent column of a 
prestored bitmap. The code that we used in that chapter to draw the individual 
columns of the bitmap can be adapted with minimal change to draw texture- 
mapped walls in a ray-casting program. The wallcasting code that we just 
developed tells us the height of the portion of the wall corresponding to a given 
column of pixels on the display, We can then use the texture-mapping code to 
draw the equivalent column of pixels from a predrawn bitmap, scaling it to the 
height of the wall column. 

In order to incorporate bitmaps into our program, we need a fle formar in 
which to store the bitmaps on the disk and an internal format for storing the 
bitmaps in the computers memory. For the first, well use PCX hles, since weve 
already created code for reading this format. For the second, well use the 
PCX_struct format we developed back in chapter 4, This internal format is a 
little wasteful of memory, since it devotes additional space to PCX header 
information that we dont really need, but its adequate for the demonstration 
that were going to write in this chapter. The PCX file, which is in the RAYCAST 
directory as IMAGES.PCX, contains fifteen 64 by 64 images arranged in three 
rows of five images. [he texture-mapping code will extract these i images directly 
from the smage held of the PCX structure. 

The program that calls our textured-mapped draw_maze() function (which is 
in the RAYCAST directory on the disk as TEXTDEMO.CPP) will need to load 
the IMAGES.PC% file (or any other PCCX file containing a set of 64 by 64 images 
arranged in this format) ising the Joga PCX() function from chapter 4 
ff Load texture map images: 

if ClLoadPCxX("images.pcex",&textmaps)) exit); 


The calling program will also need to maintain the map of the maze, as in 
previous demos, However, the format will be slightly different this time. Earlier, 
we used zeros to indicate empty maze squares and non-zero numbers to represent 
maze squares that are occupied by cubes. Now were going to us¢ specific 
numbers to indicate which texture is to be mapped onto the walls of a cube. 
Zeros will still indicate empty squares, but now non-zero numbers will indicate 
which of the 15 textures in the IMAGES.PCX file we are going to use, The 15 
images will be numbered, starting at 1 in the upper-left corner and continuing 
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lett to right atid Lop bo bottom through the image, as shown in Figure ).] 4, 
Figure 9-14 shows the map we'll be using in the demo: 


map type walls=f{ 
Cede: fended ae i ae ei eon: SAN 
t > 3,0, 5, 0,0, 9,2; 0,0, 0, 0,0,. O0,.:0, SF, 
ef O00, 0.0.0, G6, 3,428) Oo) G.68,.0, 53, 
fo Be O, 8.05 OS Oo O24 Boo te bo Oo. ok 
tf, 6,0, 0,.-0, 0,.0,-0, O,.0, 5, 4,0). 0,.0, 5%, 
(i2, 0, 0, 0, 0, 0, 0, 0, 0, 0,171,711, 0, 0, 0, 33, 
{i}, 02:0, 0.0), 0,-0,°0, 0,20,°0,17-10, 0, 0, 33; 
£11, 0,0, @,..0,. 0,0, 0, 0,0, 0,.0,10,.0, 0, 51, 
tT1, vt, Tf, G, 8.0, 0,20, 0,20, 0517, 10, 8,.0, 33, 
Ct2;, O,-0; 0,0, 0, 0, & O-0,71 19, 0,50,-0, 53, 
tig, (3 fe 0,70, 0-5, 1% 07: Go e,. 6.0, SF, 
tof, 0.0, G,.-0,00,.0, 1 0,-1,°8, 0.6, 0,.:0, 53, 
iF; 0-0, G50, 0.-0;..1, 0,-8.0 8 8,0; 8 0,12, 
{ 7, 0, 0, 0, 0, 0,-0, 1, O;.1, GO, 0,:0, 0, 0,11}, 
tf, 6,6, 6,-6, 0, 0, 1, 0, 1, 0, 0, G, 0, 0,10), 
er i em So Pee I Mie De Deeg Gee (i EO Pe De OR a 


The textured dna mazef} function, which ts in the fle TEXTCAST.CPP in 

the RAYCAST directory, has a slightly revised prototype in TEX TCAST.H: 
¥old draw_maze(map_type map,char far "sereen,1nt xview, 

int yview,float viewing angle, 

int viewer_height,char far * textmaps); 
We've now added a pointer to a char array called textmaps as the last entry in the 
parameter list. It should point to a 64,000-byte buffer containing the 64 by 64 
images to be mapped onto the walls of the maze. The calling program will call it 
with a pointer to the gage held of the PCCX structure: 


draw _maze(walls,screen,xview,¥VieW,VIeEWINg_angLe, 
vViewer_height,textmaps. image) ; 








Figure 9-14 The 15 image pasitions in 
the PCx file 
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Finding the Bitmap Column 


Much of the texture-mapped draw_maze() function will be identical to the solid- 
color one that we introduced earlier in this chapter. As before, it will be 
constructed as a large fer(/ loop that steps through all of the vertical columns in 
the viewport. The process of casting the ray will once again start out by 
calculating the angle of the current ray, in radians, relative to a ray traveling due 
north at 0 radians. It will then create an arbitrary endpoint for the ray, rotate it vo 
the current angle, and translate the coordinates of the starting and ending points 
of the ray relative to the viewers position in the maze. The ray will be cast across 
the x and y grid lines until a wall is encountered. 

The drawing of the wall will be handled a bit differently by this function, 
When the point of intersection berween the ray and the wall is calculated, a 
separate value will be calculated indicating the precise horizontal point on the 
face of the cube where the ray strikes. This value will be measured in fine 
coordinates, with the tar left side of the cube face being at coordinate 0 and the 
far right side of the cube tace being at coordinate 63, as shown in Figure 9-15, 
This value is simply the x or y coordinate (depending on whether the face is on 
an x or y grid line) taken modulo 64 — that is, the remainder after the 
coordinate has been divided by 64. We can obtain this value quickly by ANDing 
the relevant coordinate with 63 (hexadecimal 3F). If the ray strikes a face aligned 
with an x grid line, we'll AND the y coordinate to obtain the value: 
tmcolumn = Cintiy & Ox3ft; 


If the ray strikes a face aligned with a y grid line, well AND the x coordinate to 
obtain the value: 


tmeolumn = Cintix & Ox3t; 


Why are we doing this? The integer variable gmeolamn (which stands for 
“texture map column’) is now equal to the column of the 64 by 64 bitmap to be 
mapped onto that vertical column of the cube face. We can now scale this 
column, as we did back in chapter 6, to fit the visible height of the wall at the 
paint of intersection. 


Clipping the Column 


This complicates the wall clipping a bit, because we now have to reindex into the 
texture map if the wall column extends past the top of the viewport. At the 
moment, tmcolumn tells us where to find the pixel to be copied from the bitmap 
to the top of the column on the display. If no clipping were necessary, we would 
simply need to calculate the offset of the upper-left corner of the bitmap (which 
I'll show you how to do in a moment) and add ¢nce/ummn to the offset to find the 
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Figure 9-15 The column positions on a single cube fece 
aré numbered 0 to 63 from left to rare 


pixel. If the column runs off the top of the display, however, well need co index 
forward into the bitmap, as we did when clipping polygon columns in chapter 6. 

First, well create an integer variable ¢ to represent the clipped top of the 
column: 


int t=tmcolumn; 


Then well create a variable to hold the clipped height of the column: 


int dheight=height; 


Finally, well check to see whether the column extends past the top of the 
viewport and trim dheighr if it does, just as we did in the program earlier in this 
chapter: 


if (top < VIEWPORT_TOP) f 
dheight-=(VIEWPORT_TOP - top); 


Now we need to adjust the variable ¢ to point to the birmap pixel thar will be 
at the top of the clipped column. We've already done this in chapter 6. To 
reiterate, this operation is a little tricky because the pixels in the column as it will 
be drawn on the screen dont have a one-to-one correspondence with the pixels in 
the bitmap being copied to the column, If the wall is nearby, the pixels may be 
expanded to two or three times their normal size as the birmap ts scaled to the 
column size. If it’s far away, some of the pixels may be skipped altogether. We 
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know that VIEWPORT_TOP - top pixels have been clipped from the top of the 
column on the screen, but how many pixels does this represent in the 
corresponding column of the bitmap? To find out, we must calculate the ratio 
berween the visible size of the wall and the size of the bitmap: 


float yratio=(float)height/WALL_HEIGHT; 


Then we must multiply this value by VIEWPORT_TOP - top to find our how 
many pixels of the bitmap have been trimmed: 
t+=(VIEWPORT_TOP-top)*yratio*320; 


Youll notice that we multiply the resulting value by 320 in order to advance it to 
the proper row of the bitmap containing the image. (The image to be mapped 
onto the wall ts only 64 pixels wide, so you might wonder why we dont multiply 
this by 64. The bitmap in which the image is stored, however, is 320 pixels wide, 
so we must advance by that amount to reach the next column of the bitmap that 
t will be pointing to.) We then advance rt by this value. 

The clipping of the bottom of the column against the bottom of the viewport 
proceeds exactly as it did in the last program. There's no need to clip the bitmap 
against the bortom, since well simply stop drawing when the bottom is reached, 
leaving the remainder of the bitmap uncopied. 


The Error Term Revisited 

As in chapter 6, we'll be using incremental division to determine when tt is 
necessary to advance one more row farther into the bitmap, So we must initialize 
a vertical error term: 


int tyerror=IMAGE_HEIGHT; 


If youre hazy on how the error term works, you might want to reread chapter 6, 
as well as the material on Bresenhamss algorithm in chapter 2. We'll see in a 
moment why the error term has been initialized to the height of the bitmap. 

We then proceed as before, setting the integer variable m/e equal to the value in 
the wiafl// array for the square occupied by the cube that we are now drawing: 


int tile=maplxmazeJCymazel-1; 


We subtract 1 from this value because there is no way that we can represent 
image 0 in the wall// array, thar number being used to represent empty squares. 
However, in order for the following calculations to work correctly, the images in 
the first row must be numbered 0 through 4, the images in the second row 5 
through 9, and so forth. Subtracting | converts a 1 value in the map to represent 
image 0, a 2 to represent image 1, and so forth. 
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Now we need a variable thar will point to the upper-left corner of the bitmap 
co be drawn in the fextmaps buffer, You'll recall that the images in this buffer are 
arranged in three rows of five images cach. To calculate which row the image Is 
in, we can divide tile by 5. To get the actual offset at which this row starts, we can 
multiply the height of the images (in the constant IMAGE _HEIGHT, which has 
been set to 64) by 320 and multiply the result by the number of the row. Finally, 
we must take the number of the tile modulo 5 to get the position of the image in 
the row, multiply the result by the width of an image to get the offset within the 
row, and add the result to the offset of the row: 


unsigned int tileptr=(tile/5)*S20* IMAGE _HEIGHT+(tilez5) 
*IMAGE WIDTH+t: 


Adding ¢ to the result gives us the actual offset of the next pixel to be drawn 
within the overall bitmap butter. 

We'll use a for() loop to draw the column: 
for (int h=O; h<IMAGE_HEIGHT; h++) f 
This loop will execute once for every pixel in the original bitmap, rather than 
every pixel on the display, This guarantees that we wont inadvertently overstep 
the bottom of the bitmap and copy pixels to the display that don't belong. 

To decide if we need to draw a pixel on the next loop, we'll check to see if the 
value of Herror is greater than or equal to the height of a column of the bitmap: 
while (tyerror>=IMAGE_HEIGHT) { 

Earlier, we initialized tyerrer to 64, to the value of the IMAGE_HEIGHT 
constant, which guarantees that the first pixel in the column will be drawn, 

If the error term ts greater than or equal to IMAGE_HEIGHT, we copy the 


current pixel trom the bitmap to the viewport: 


screenLoffsetJ=textmapsltileptrd; 


We then reset the error term by subtracting IMAGE HEIGHT from ir: 
tyerror~=[IMAGE_HEIGHT; 


and we move offser to point at the next line in the viewport: 

offset+=320; 
I 
That closes the while() loop. If the error term is still greater than 
IMAGE HEIGHT after IMAGE HEIGHT has been subtracted from ir, the 
loop will execute again — and will continue executing until the error term is less 
than IMAGE_HEIGHT. This causes the pixels to be enlarged when the screen 
column is longer than the column in the bitmap. 
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Now we start the process all over agaln by adding the unclipped height of the 
screen column to the error term: 


tyerrort=height; 


If this causes the error term to become greater than the height of a bitmap 
column, the next pixel in the bitmap will be drawn next time the loop repeats. If 
not, pixels will be skipped until the cumulative adding of the eight value to the 
error term pushes it over the threshold, Before we can draw the next pixel in the 
bicmap column, however, we must advance trleprr to point at it: 
tileptr+=520; 
. 
} 
} 


That terminates all loops. The walls have now been drawn. The complete 
texture-mapped ray-cast dntu_magze(/ function appears in Listing 9-3. 


The Texture-Mapped Ray-Cast draw_maze() Function 





Listing 9-3 The draw_maze() function 


ff TEXTCAST.CPP 


‘*/ Function to draw texture-mapped walls using ray—casting. 
f/f Written by Christopher Lampton for 
‘/ Gardens of Imagination (Waite Group Press). 


Ainclude <stdio.h> 
Hinclude <math.h> 
finclude “textcast.h" 
Finclude "“pex.h" 
Hinclude “distance.h" 
finclude “slope.h" 


/* Constant definitions: 


const WALL_HEIGHT=64; // Height of wall in pixels 
const VIEWER_DISTANCE=192; // Viewer distance from screen 
const VIEWPORT_LEFT=0; ff Dimensions of viewport 


const VIEWPORT_RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT _HEIGHT=VIEWPORT_BOT-VIEWPORT_TOP; 
const VIEWPORT CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/2; 
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void draw_maze(map type map,char far *screen,int xview, 
int yview,float viewing_angle, 
int viewer_height,char far * textmaps) 


‘f Draws @ fray=cast image in the viewport of the maze represented 
// in array MAPCI, as seen from position AVIEW, YVIEW by a 

f/f viewer Looking at angle VIEWING ANGLE where angle 0 15 due 

ff north. CAngles are measured in radians.? 


‘/ Variable declarations: 
int sy,offset; // Pixel y position and offset 


float columnm_angle=atan(( float) (column-160) 
/ VIEWER_DISTANCE); 
if (column_angle==0.0) column_angle=0.001; 


‘/ Calculate angle of ray relative to maze coordinates 
float radians=viewing_angle+column_angle; 


ff Rotate endpoint of ray to viewing angle: 
int x2 = -1024 * (sintradians?); 
int ¥2 = 1024 * (Cecostlradians)); 


‘if Translate relative to viewer's position: 
Ket=xvVIieW; 
¥et=¥VIeH; 


ff Initialize ray at viewer's position: 
float x=xview; 
float y=yview; 


‘i Find difference in x,y coordinates along ray: 
float xdiff=x2<-xview; 
float ydiff=ye-yview; 


// Cheat to avoid divide-by-zero error: 
if (xdiff==0) xdiff=0.0001; 


‘/ Get slope of ray: 
float slope = ydiff/xdiff; 


// Cheat (again) to avoid divide-by-zero error: 
if (stope=-0.0) slope=.0001; 


/* Cast ray from grid Line to grid Line: 
for C72 4 


ff If ray direction positive in x, get next x grid Line: 
if (editft=0) grid_x=(Cintix & Oxf fcO)+64; 


ff If pay direction negative in x, get Last x grid Line: 
else grid_x=(Cintix & Oxtfel) = 1; 
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/? If ray direction positive in y, get mext y grid Line: 
if (ydiff20) grid_y=(Cint)y & OxffcO) +64; 


ff If ray direction negative in y, get last y grid Line: 
else grid_y=(Cintiy & OxffcO} -— 1; 


// Get x,y coordinates where ray crosses x grid Line: 
xCPOSS x=grid x; 
xcross y=y¥y+slope*(grid_x—x); 


// Get x,y coordinates where ray crosses y grid Line: 
yoross x=x4+(grid_y-y)/slope; 
¥Cross_y=grid_y; 


/f Get distance to x grid Line: 
xd=xcross x—-«; 

yYd=xcross_y-y; 
xdist=sqrt(xd*xd+yd* yd); 


f/f Get distance to y grid Line: 
xd=yeross_xX—x; 

yd=ycross_yy¥; 
ydist=sqrt(xd*xd+yd*yd) ; 


ff It x grid line is closer... 
if (xdist<ydist) f 


ff Caleulate maze grid coordinates of square: 
xMaze=xcross_x/64; 
y¥maze=xcross_y/64; 


ff Set x and y to point of ray intersection: 
X=KXCrOSS x; 
Y=XCross_¥; 


ff Find relevant column of texture map: 
tmeolumn = Cintdy & Ox3t; 


f/f Is there a maze cube here? If s0, stop Looping: 
if (maplxmazelJLymazel) break; 

} 

else { // If y grid line is closer: 


if Caleulate maze grid coordinates of square: 
umaze=ycross_“/G64: 
ymaze=ycross_y/64; 


// Set x and y to point of ray intersection: 
X=YCrOSS_x; 
Y=ycross_¥; 


// Find relevant column of texture map: 
tmcolumn = Cint)x & Ox3f; 
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ff Is there a maze cube here? If so, stop looping: 
if (mapCxmazellymaze]) break; 
} 
} 


/f Get distance from viewer to intersection point: 
xd=x-xview; 

yo=y=-yvV1eH; 
distance=(Long)sqrt(xd*xd+yd*yd)*cos(column_angLle); 
if (distance==0) distance=1; 


‘ff Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 


ff Calculate bottom of wall on screen: 
int bot = VIEWER_DISTANCE * viewer_height 
/ distance + VIEWPORT_CENTER; 


ff Calculate top of wall on sereen: 
Int top = bot — height; 


ff Initialize temporary offset into texture map: 
int t=tmeolumn; 


‘f If top of ¢urrent vertical line is outside of 
‘i wiewport, clip it: 


int dheight=height; 

if (top < VIEWPORT_TOP) f 
dheight-=(VIEWPORT_TOP - top); 
float yratio=(float}height/WALL_HEIGHT; 
t+=(VIEWPORT_TOP-top)*yratio* 320; 
top=VIEWPORT_TOP; 

} 

if (bot > VIEWPORT_BOT) 
dheight -= (bot — VIEWPORT_BOT); 


// Point to video memory offset for top of Line: 
offset = top * 320 + column; 


/f Initialize vertical error term for texture map: 
int tyerror=IMAGE_HEIGHT; 


// Which graphics tile are we using? 
int tile=mapCxmazeJLymaze]-1; 


/f Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*420* IMAGE HEIGHT+(tiles5?} 
*TMAGE WIDTH+t; 


ff Loop through the pixels in the current vertical 
// Line, advancing OFFSET to the next row of pixels 


‘f after each pixel is drawn. 
comiricd i Hex? fader 
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confined fem preven page 


for Cint h=O; h<IMAGE_HEIGHT; h++) { 


/f Are we ready to draw a pixel? 
while (tyerror>=IMAGE_HEIGHT) ¢ 


‘f If so, draw it: 
screenLoffsetJ=textmapsltileptrid: 


// Reset error term 
trerror-=[MAGE HEIGHT: 


ff And advance OFFSET to next screen Line: 
offset+=320; 


‘f/f Incremental division: 
tyerrort=height; 


ff Advance TILEPTR to next Line of bitmap: 
tileptr+=320; 


To see this code in action, go to the RAYCAST directory and type 
TEXTDEMO. You'll see a texture-mapped view of the maze walls as they look 
from the center of the room at an angle of 0 radians, as shown in Figure 9-16. To 
see the view from other angles, type a number of radians from 0 to 6.2 after the 
name of the program. Figures 9-17a through e show the maze from angles of 1, 
2, 3, 4, and 5 radians, You can also use fractional radian values to get more 
precise views of the maze. 

The improvement over the earlier solid-color ray-casting program is striking. 
The texture-mapped walls look quite vivid and dramatic. We're well on our way 
to creating a topnotch ray-casting engine. 





Figure $16 The maze wewed from an 
angle of 0 radians, as depicted by the 
TEXTOEMD program 
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Figure 9-17a-e The maze as seen from Figure 9-17b 


anoles of 1. 2. 3. 4, and 5 racians, 
respectively 





Figure 9-17¢ Figure 9-17d 





Figure 9-17e 


Floorcasting 


Truth to tell, we now have almost enough ray-casting code to write an arcade 
game along the lines of Wolfenstein 3D. All we need is some additional code for 
drawing bitmapped objects, such as treasure chests and Nazi guards, and wed have 
a clone of the Wolf 3D engine. (Actually, this isnt quite true. The Wolfenstein 3D 


ce 
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engine appears to use texture-mapped polygons to represent doors and sliding 
walls, but well ignore that detail for the moment.) We can now draw the walls of 
a texture-mapped maze, which is pretty much all thar Wolfenstein 3D does to 
generate scenery. (The floors and ceilings are drawn in solid colors, burt these can 
be laid down before the ray casting begins.) 

However, the technology of ray casting has proceeded apace since Wolfenstein 
3D came on the scene. [ts no longer enough just to display texture-mapped 
walls. A ray-cast game needs to display texture-mapped floors and ceilings as well. 
So well now develop a Hoorcasting version of our engine. The first version will 
drawn enly texture-mapped floors and ceilings, then we'll create a second version 
that will combine the Hoors with the walls. Ready? Let's go. 

The program that calls our floorcasting drawmaze() function will need to 
maintain rid arrays, one To represent the Map of the floor, the other to represent 
the map of the ceiling. Each element in these arrays will represent the number of 
the bitmap in the IMAGES.PCX file to be mapped onto the corresponding 
segment of floor or ceiling. Since each square of the maze measures 64 by 64 in 
the fine coordinate system, there will be a perfect correspondence berween the 
pixels in the bitmap and the points in the fine coordinate system, with one pixel 
per fine coordinate point, Here are the two arrays that well be using: 


map type flor= 


i Be ae ie ee ie On| Bie lt a elie Ne cal Bis 
{ 5, 5, 3p Sp Sp Sp Dp Sp Je Se Oe Se de Sy ae ote 
{ 5,5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5}, 
(5; 9.55.55. Sy So: §,.S% $55,555.55 5.055 53; 
CS by ep Spo eee eo De ee dacs ap 
{ 5, 5, 5, 8, 8, 6) 3, 3, 3p 3p De Je Fe Fy Sy FT, 
{ 5, 3, 8, 8, 8, &, 8, 3, 5, 3, 37 3, Je 4, 5, 3), 
{'§: 5.5, 8..8,:8..5, 55 5,5, 5, 5, 5, 5,55 53; 
Cis Seccke Oe ape Spe eee, ie ee cle oe 
{ 3, 5, 3, Sp 3p 37 Se 3p Je Se te Se Se 4p 5y 3); 
{ 5, 5, 5, 5, 5, 5; 5, 5, 5, 5, 5, 5, 5, 5, 5, 5}, 
cos Be a ee ie es Me oes Op a Sl 
CS Se aie Seep eric ite Stairs Ol ae Oke die: at 
(5, ieee te de eee dee ip oy op apy Op 
{ 5, 5,5, 5 5, 5..5, 5s 5,.5,.5, 5,5) 5, 5, 53, 
ao SSS a epee ep ee eee ce ape oie de ae 


he 
* 


map type ceiling=t 
{13,173,15,15,13,173,15,15,15,135,13,13,13,135,13, 13), 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13}; 
{13,13,13,13,13,13,13,15,13;13,13,13,13,13,13,13}, 
(13,135,135, 13,15,15,15,135,15,15,13,15,13,13,13, 13}, 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13, 13, 
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{13,13,13,13,13,13,)3¢135-13,15¢lap los log log lode 13h, 
{13,13,13,13,13,13,13-13,15,13,13,13,15,13,13,135}, 
15,135,135, 135, 13,13, lop lop los lay boy op 13, 1, oy lal, 
{13,13,13,13,13,15,-)3¢l3eloelap lay lae layla ld, 15h, 
{13,13,,13,15,13,13,13,13,13,135,13,13,13,13,13,15}, 
(75,13,135,15,13,15,15,13,15,135,15,13,15,14, 13,13), 
{13,13,13,13,13,13,13,-13,13,13,13,15,15,13,15,15}, 
{13,13,15,15,13,13,13,13,13,13,13,13,13,13,13,13}, 
£135,135, 15,135;15, 13513, 13; 13515, 15; 15,135; 13, 13,135), 
{13,13,13,13,13,13,13,13,13,13-13,13,13,1l3-13,13}, 
{13,13,13,15,13,13, 13, la¢l3elo¢l3-1o, lo, layla, lat 

}; 


We've called the first array flor// instead of floor// so that the linker wont mistake 
it for a reference to the C++ ffoor() function when we attempt to pass a pointer to 
it In a parameter list. 
Once again, the prototype of the function, in FLOORCST.H, will need to be 
modihed slightly from earlier versions: 
void draw_maze(map_type floor,map_type ceiling,char far “screen, 
int xview,int yview, 


float viewing angle,int viewer_height, 
char far *textmaps); 


We've now added the floor and cetling arrays to the parameter list and have 
dropped the wil array, since we have no need for it in this function. 

As before, the function is constructed as a large fer() loop that iterates through 
all of the columns in the viewport. And we start out by calculating the angle 
of the ray Case through the CUIrrent column relative co north, storing 
the resulting angle in the Hoating point variable radians. At this point, however, 
the Hoorcasting function takes off in a completely different direction. 

Here's what it will do: We will start at the bottommost pixel in the column, 
the One at the ¥Cry bortom of the viewport, and Cast a fay through thar column. 
Well determine where it strikes the Hoor, in terms of the ne coordinate system, 
then determine the color of the pixel at that point. Then well draw that pixel in 
the viewport, We'll continue doing this for all of the pixels in the bottom half 
of the viewport. (Actually, we'll stop 5 pixels shore of the center of the viewport, 
to give the impression that the more distant Hoor pixels have faded into darkness. 
When we combine the floorcasting code with the wallcasting code, well simply 
stop casting when we reach a wall.) 

We'll use a second fer() loop to step through all of the pixels in the lower 
portion of the column, from the one at the bottom of the viewport to the one 5 
pixels short of the vertical center: 


for (int row=VIEWPORT_BOT; row>VIEWPORT_CENTER+5; --row) @ 
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The Similar Triangles Method 

Now we need to determine what color the pixel in that position should be, which 
means that we must cast a ray through that pixel to determine where it hits the 
floor, But how do we do this? Look at Figure 9-18. It shows the viewer looking 
through the video display at the floor of the maze. The line coming out of the 
viewers eyes and striking the Hoor is labeled B, Another line runs from the 
viewers feet to the position where the ray strikes the floor, We've labeled this A. 
Finally, the line that runs from the viewers eyes to the Hoor ts labeled C. 

Youll notice that these lines, taken together, form a triangle. We know the 
length of one side of this triangle, side C (the one that runs from the viewer's eye 
to the floor). (t's contained in the parameter viewer_height that was passed from 
the calling program.) We went to know the length of A, from which we can 
calculate the coordinates of the floor pixel struck by the ray. We could use 
trigonometry to calculate this length, but theres an easier way, one that lends 
itself more to optimization, It’s called the similar triangles method, 

Look at Figure 9-19. The same triangle from Figure 9-18 is depicted here, bur 
now a second triangle has been nested inside of it. One edge of this triangle, 
running parallel to line C in the big triangle, is labeled c This edge represents the 
height of the viewer's eye above the row through which we are casting. The line 
labeled @ in the small triangle is the distance from the viewer to the display. It 
runs parallel to line A in the big triangle. And the line labeled 4 in the small 
triangle is the straight line distance from the viewers eye to the row through 
which the ray has been cast. This line runs parallel to line B in the big triangle. 
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Because all of the lines in the small triangle are parallel to lines in the big 
triangle, we know that all of the angles berween sides in the small triangle must 
be the same as the angles between sides in the big triangle, even though the 
lengths of the sides are different. In mathematical terms, two triangles in which 
all of the angles between the sides are the same bur the lengths of the sides are 
different are called stmtlar triangles. According to the Law of Similar Triangles, 
the ratio between the sides of a similar triangle are always the same no matter 
what the actual lengths of the sides are. If one side is 1.5 times the length of 
another in a small triangle, it will be 1.5 times the size of the other in a larger 
version with the same angles. In algebraic terms, we would write: 


A/C = a/c 


where the letters refer to the sides of our similar triangles. 

We already know the lengths of three of these sides, C is the value of the 
parameter eiewer_hetght, ais the value of the constant VIEWER_DISTANCE, 
and ¢can be easily calculated by subtracting VIEWPORT_CENTER (the row of 
the viewport with which the viewer's eyes are supposedly aligned) from row (the 
row we are casting the ray through), We need to solve this equation for A, 
Following the standard algebraic rules, we can rewrite the equation as: 

A= ale *¢C 


Plugging in the values from our program, we get: 


distance_to pixel = VIEWER_DISTANCE/(VIEWPORT_CENTER - row) * 
viewer_height 
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Figure 9-19 The small triangle with sides a, b, c is mathematically similar to the large triangle 


with sides 4, B, ¢ 
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In the actual program, well code that slightly differently. First we'll perform 
the division and store the value in the Hoating point variable nati, since the result 
of the division is the ratio between the sides: 


float ratio=(floativiewer_height/(row-VIEWPORT_CENTER): 


Then we'll multiply the result by VIEWER_DISTANCE to get the actual 
distance of the pixel from the viewer. We'll also perform the cosine adjustment, as 
explained earlier in this chapter, to avoid a fish-eye effect: 


distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


Now well rotate this distance around the origin to the angle that we stored 
earlier in the variable radians: 


int x 
int ¥ 


- distance * (sinfradians)); 
distance * (cos(radians))}; 


(This is the same calculation that we used during wallcasting, explained earlier in 
this chapter.) Then we'll translate the resulting coordinates relative to the viewers 
position: 
et=KVIEW; 
yreyview; 

In order to find the pixel color for this position in the maze, we need to know 
which maze grid square it’s part of: 


i 64; 


int xmaze = x 
=y / 64; 


int ymaze 

We also need to know the column of texture map that should be applied to 
this pixel. Well find it by taking both the x and y coordinates positions modulo 
64, and using the result to calculate the necessary index into the bitmap buffer 
relative to the upper-left corner of the bitmap: 


int t = (lintiy & OxSf) * 320 + (Cintix & Oxf); 


Once again, weve used 320 as the bitmap width rather than IMAGE_ WIDTH 
because the bitmaps are stored in a bufter 320 pixels wide. 

The number of the image tile that well be using is stored in the fleor// array. 
(We've called the array floor// within the function rather than ffor//, because the 
context in which we'll be using it here makes it clear that were not referring to 
the foor() function.) We can use the xmaze and ymaze values, as before, to obtain 
the element with the number of the tile: 


int tile=floorlxmazelLymazel; 
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Well calculate the offset of the upper-right corner of the bitmap exactly as 
before: 


unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tiles5> 
*TMAGE_WIDTH+t; 


Similarly, we'll calculate the video memory offset of the current row in the 
Current column using the standard calculatio [: 


offset=row*320+column; 


Finally, we ll copy the pixel from the bitmap to the viewport: 


screenLoffsetJ=textmapsltileptrd; 
} 


And thars all there is to drawing the Hoor, 


Drawing the Ceiling 


Well draw the ceiling almost exactly as we drew the floor. The easiest way to 
draw the ceiling would be to draw it at the same time as we draw the Hoor, 
mirroring every Hoor pixel with a ceiling pixel in the upper half of the viewport. 
That would be faster than what were actually going to do, but it would assume 
that the viewers eye height is hxed midway between the floor and ceiling. This 
will often be the case — in fact, many ray casters work on this assumption — but 
we ll make the ray caster thar we develop in this chapter a bic more versatile. 
Thats why weve passed wrewer_hbeight as a parameter from the calling program, 
so that it can be varied dynamically if necessary. But this means we'll have to cast 
the ceiling separately, recalculating all of the numbers from scratch. Instead of 
starting with the botrommost pixel in the viewport and advancing until were 5 
pixels below the center, well starr with the ropmost pixel in the viewport and 
advance until we're 5 pixels above the center: 


for Crow=VIEWPORT_TOP; row<VIEWPORT_CENTER<5; rowt+) { 


We can use the similar triangles method to calculate the distance to the ceiling 
pixel just as we did when we calculated the distance to the floor pixel, except that 
the triangles will be upside down. Instead of dividing viewer_herght from 
VIEWPORT_CENTER-rew to get the ratio of the two sides, we'll divide 
WALL HEIGHT -viewer_beighe (the distance from the viewer's eyes to the maze 
ceiling) by VIEWPORT_CENTER-rew (the distance from the viewers eyes to 
the row through which we're casting the ray): 


float ratio=( float) (WALL_HEIGHT=-viewer_height) 
/ (VIEWPORT_CENTER-row) ; 
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We can then calculate the distance to the floor pixel and the coordinates of the 
Hoor pixel just as we did for the Hoor. However, well need to take the tile 
number from the ceéling// array rather than the floer// array: 


int tile=ceiling[xmazel[ymazel; 


The remaining code is identical to the code for casting the floor. And that’s the 
rest of the Hoorcasting drawmaze() function, The complete text of the function is 
in Listing 9-4. 


The Floorcasting draw_maze(Q) Function 






“=e Listing 9-4 The floorcasting draw_maze() function 


if 

ff FLOORCST.CPP 

‘/ Draws texture mapped floor 

‘/ Written by Christopher Lampton 

‘/ for Gardens of Imagination (Waite Group Press} 


Finclude <stdio.h> 
Finclude <math.h> 
Ainclude "floorcst.h" 
Ainclude "pex.h" 


const WALL_HEIGHT=64; // Height of wall in pixels 
const VIEWER_DISTANCE=12é; ‘*f Viewer distance Trom screen 
const VIEWPORT_LEFT=0; // Dimensions of viewport 


const VIEWPORT_RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT_BOT-VIEWPORT_ TOP; 
const VIEWPORT_CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/2; 
const ZOOM=2; 


void draw_maze(map_type floor,map_type ceiling,char far *screen, 
int xview,1nt yview, 
float viewing _angle,int viewer_height, 
char far *textmaps) 


int younit,x_unit; // Variables for amount of change 
‘f/f in x and y 
int distance,old_distance,xd,yd,sx,sy,otfset; 


// Loop through all columns of pixels in viewport: 


for €int columm=VIEWPORT_LEFT; columnm<VIEWPORT_RIGHT; column++) 
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‘/ Calculate horizontal angle of ray relative to 

ff center ray: 

float column_angle=atan(( float) ((column-160)/7004) 
/ VIEWER _DISTANCE); 


‘/ Calculate angle of ray relative to maze coordinates 
float radians=viewing_angle+column_angle; 


f/f Step through floor and ceiling pixels: 
for Cint row=VIEWPORT_BOT; row>VIEWPORT_CENTER+5; -—-row) f 


// Get ratio of viewer's height to pixel height: 
float ratio=(float)}viewer_height/(row-VIEWPORT_ CENTER): 


ff Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


// Rotate distance to ray angle: 
int x = -— distance * (sint(radians)}; 
int y = distance * Ccos(radians)); 


if Translate relative to viewer coordinates: 
Kt=KVIEN; 
yr=yview; 


ff Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 


if Find relevant column of texture map: 
int t = (Cintdy & Ox3f) * 320 + CCintdx & Ox3f); 


/f/ Which graphics tile are we using? 
int tile=floorlxmazellymazel; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(ti1le/5)*320* IMAGE HEIGHT+(tilesrs) 
*IMAGE_WIDTH+t; 


/f Calculate video offset of floor pixel: 
offset=row*320+coLlumn; 


/* Draw pixel: 
screenLoffset J=textmaps(tileptrid; 
} 


// Step through ceiling pixels: 
for Crow=VIEWPORT TOP; row<VIEWPORT_CENTER-5; row++) 1 


// Get ratio of viewer's height to pixel height: 
float ratio=(float} (WALL HEIGHT-viewer_height) 
f (VIEWPORT _CENTER=row) ; 
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// Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


// Rotate distance to ray angle: 
int « = - distance * (sintradians)); 
Int y = distance * (cos(radians)); 


/f Translate relative to viewer coordinates: 
x+=xVieH; 
y+=yvileH, 


// Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64: 


‘* Find relevant column of texture map: 
int t = (Cint)y & OxSf) * 320 + (Cintix & OxSt); 


‘f Which graphics tile are we using? 
int tile=ceilingl xmazellymazel; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tilexs) 
*IMAGE_WIDTH+t; 


‘/ Calculate video offset of floor pixel: 
otfset=row*320+column; 


if Draw pixel: 
screenLoffsetJ=textmaps(tileptrd; 


To see what this function does, go to the RAYCAST directory and type 
FLOORDEM. You'll see a view of a texture-mapped maze floor and ceiling 
stretching out into the distance (see Figure 9-20), I've deliberately used the same 
tile repeatedly in both the Hoor and the ceiling because this is how floors 
normally look. If you turn to an angle of approximately 3 radians — by typing 
the number 3 after the name of the program when executing it — youll see a 
cross on the Hoor constructed out of an alternate bitmap (see Figure 9-21). At 
some angles, you may notice some oddly colored floor tiles off in the distance. 
These are drawn when the floorcasting algorithm works its way off the ends of 
the floor!) and cerling// arrays, since we've performed no bounds checking to keep 
this from happening. When we add the walls, irc wont be necessary to check for 
boundary violations, since the Hoorcasting will stop when a wall is encountered, 

So let's add some walls, by combining our Hoorcasting code with our texture- 
mapped wallcasting code. 


—_———— 
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Figure 9-20 4 téxture-mapped ray-cast Figure 9-27 Across of tiles in the 
floor and ceiling as depicted by the middie of the floor 


FLOGREDEM program 


A Complete Ray-Casting Engine 
Combining the wallcasting and Hoorcasting code ts a relatively trivial task, Well 
need to modify the protorype for the draw_maze() function yet again, so that we 
can pass pointers to Sree two-dimensional arrays: the wall// array, the floor// 
array, and the cer/ing// array: 
void draw _maze(map_type map,map_type floor,map_type ceiling, 

char far *screen,1nt xview,1nt yview, 


float viewing_angle,int viewer_height, 
char far * textmaps) 


In the demo program that we create (which is in the module RAYDEMO.CPP), 
we ll use the same arrays for the walls, Hoors, and ceilings that weve used in our 
earlier demos. [he draw _maze() function itself will be in the module 
RAYCAST.CPP and the protorype in RAYCAST.H. 

In writing this new version of the draw_maze() function, the major decision 
we find ourselves faced with is the order in which to perform the operations. 
Should we cast for the walls first or draw the Hoors first? 

This isnt a difficult decision to make. If we draw the Hoors first, we'll need to 
draw the walls over them, which means that a lot of the screen pixels will be 
drawn twice. Thats time-consuming. Even though the code that we're writing in 
this chapter isnt optimized for speed, we want to construct the function in such a 
way that it can be easily optimized later. So we'll draw the walls first, then draw 
the ceilings and Hoors only in the areas where no walls have been drawn, 

We'll start out by casting the walls exactly as we did in the WALLCAST.CPP 
module earlier in this chapter. When we finish drawing the walls, the row 
number of the bottommost pixel in the wall column will be stored in the 
integer variable Sef, and the row number of the topmost pixel will be stored in 
the integer variable top. Instead of drawing the Hoor pixels from the bottom of 
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the viewport to the center, well start drawing just below bot and work down to 
the bottom of the viewport: 

for (int row=bot+1l; row<=VIEWPORT_BOT; rowt++) { 

And when we draw the ceiling, well start at the pixel just above top and work our 
way to the top of the viewport: 

for (row=top-1; row>=VIEWPORT_TOP; --row) { 


Thats just about the only part of the code thar needs to be altered. The resulting 
Hoorcasting, wallcasting version of the aratw_maze() function is in Listing 9-5, 


The Floorcasting, Wallcasting draw_maze() Function 





Listing 9-5 The floorcasting, wallcasting draw_mazet) 
function 


f/f RAYCAST. CPP 

fi 

// Function to draw texture-mapped walls, floors and 
ff ceilings using ray casting. 

ff Written by Christopher Lampton for 

// Gardens of Imagination (Waite Group Press). 

fi 


Ainclude <stdio.h> 
Hinclude <math.h> 
finclude "raycast.h" 
Finclude "pex.h" 
Finclude “distance.h” 
Ainclude “slope.h" 


ff Constant definitions: 


const WALL_HEIGHT=64; // Height of wall in pixels 
const VIEWER _DISTANCE=192; ‘i Viewer distance from screen 
const VIEWPORT_LEFT=0; // Dimensions of viewport 


const VIEWPORT_RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT _BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT_BOT-VIEWPORT_TOP; 
const VIEWPORT _CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/2; 


void draw_maze(map_type map,map_type floor,map_type ceiling, 
char far *sereen,int xview,int yvi1ew, 
float viewing_angle,int viewer_height, 
char far * textmaps) 


if 
if 
fi 
fi 
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Draws a ray cast image in the viewport of the maze represented 
in array MAPCI, as seen from position XVIEW, YVIEW by a 

viewer Looking at angle VIEWING_ANGLE where angle 0 is due 
north. (Angles are measured in radians.) 


ff Variable declarations: 

int sy,offset; ff Pixel y position and offset 

float xd,yd; ‘/ Distance to next wall in x and y 
int grid_x,grid_y; /f Coordinates of x and ¥ grid Lines 
float xcross_x,xcross_y; // Ray intersection coordinates 
float ycross_x,ycross_y; 

unsigned int xdist,ydist; // Distance to x and y grid Lines 


int xmaze,ymaze; ‘f Map Location of ray collision 
int distance; // Distance to wall along ray 
int tmcolumn; ‘/ Column in texture map 


float yratio; 


‘/ Loop through all columns of pixels in viewport: 
for Cint columm=VIEWPORT_LEFT; column<VIEWPORT_RIGHT; calumn++) f 


/? Calculate horizontal angle of ray relative to 
ff center ray: 
float column_angle=atan( (float) (column-160) 

/ VIEWER DISTANCE): 


/f Calculate angle of ray relative to maze coordinates 
float radians=viewing_angle+column_angle; 


// Rotate endpoint of ray to viewing angle: 
int x2@ = -1024 * (sintradians));: 
int ye = 1024 * (cos(radians)); 


/f Translate relative to viewer's position: 
MEt=EVIEW; 
yet=yview; 


// Initialize ray at viewer's position: 
float x=xview; 
float y=yview; 


// Find difference in x,y¥ coordinates along ray 
int xdiff=xe-xview; 
int ydiff=y2-yview; 


// Cheat to avoid divide-by-zero error: 
1f Cxdiff==0) xdiff=1; 


// Get slope of ray: 
float slope = (float)ydiff/xdiff; 


/f Cheat Cagain) to avoid divide-by-zero error: 
if (slope==0.0) slope=.0001; 


i 
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cominucd from previows purge 


/f Cast ray from grid Line to grid Line: 
for C27 


f/f If ray direction positive in x, get next x grid Line: 
if (xdiff>0) grid x=(Cintix & OxffcO)+64; 


ff If ray direction negative in x, get last x grid Line: 
else grid_x=((int)x & OxffcO) - 1; 


f/f If ray direction positive in y, get next y grid Line: 
if Cydiff>0) grid_y=(Cintiy & OxffcO) +44; 


ff If ray direction negative in y, get Last y grid Line: 
else grid_y=(Cintiy & OxffcO) - 1; 


ff Get x,¥ coordinates where ray crosses x grid Line: 
XCrOSS_K=grid_x; 
xcross_y=y+tslope*(grid_x-x); 


ff Get x,¥ coordinates where ray crosses y grid Line: 
ycross_x=xt(grid_y-y)/slope; 
ycross_y=grid_y; 


/f Get distance to x grid Line: 
Md=McCross_x=-x; 

yd=xcross_y-y; 
xdist=sqrt(xd*xdt+yd* yd) ; 


// Get distance to y grid Line: 
xd=ycross x-%; 

yd=ycross_y-¥; 
ydist=sqrt(xd*xdtyd*yd) ; 


ff If x grid Line ts closer... 
if (xdisttydist) { 


ff Calculate maze grid coordinates of square: 
xmaze=xcross_x/64; 
yMaze=xcrass_y/64; 


f/f Set x and y to point of ray intersection: 
K=KCross_x; 
Y=xCross_¥; 


‘f/f Find relevant column of texture map: 
tmeolumn = Cintdy & Oxf; 


‘f/f Is there a maze cube here? If so, stop Looping: 
if (maplxmazellymazel) break; 
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else i // If y grid Line is closer: 


f/f Calculate maze grid coordinates of square: 
yMaFe=yeross x/ 64: 
ymMaze=yoross_y/64; 


ff Set x and y to point of ray intersection: 
XEyCross x; 
y=yeross ¥; 


f/f Find relevant column of texture map: 
tmcolumn = Cintix & Oxf; 


/f Is there a maze cube here? If so, stop Looping: 
if (maplxumazelLymazel]) break; 
} 
} 


ff Get distance from viewer to intersection point: 
xd=e—"KVIeW; 

yd=y-yview; 
distance=(Long)sort(xd*xdt+yd*yd)*cos(column_angle); 
if (distance=-0) distance=1; 


ff Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 


ff Calculate bottom of wall on screen: 
int bot = VIEWER_DISTANCE * viewer_height 
/ distance + VIEWPORT_CENTER; 


ff Calculate top of wall on sereen: 
int top = bot — height; 


// Initialize temporary offset into texture map: 
Int t=tmeolumn; 


ff If top of current vertical Line is outside of 
// wiewport, clip it: 
int dheight=height; 
int iheight=IMAGE HEIGHT; 
yratio=(float)WALL_HEIGHT/height; 
if (top < VIEWPORT TOP) 4 
dheight==(VIEWPORT_TOP - top); 
t+=Cint) ((VIEWPORT_TOP-top)*yratio)*320; 
jheight -—= (CVIEWPORT_TOP-top)*yratio); 
top=VIEWPORT_ TOP; 
} 
if (bot > VIEWPORT_BOT) f 
dheight -= (bot - VIEWPORT_BOT); 
jheight -= (bot -— VIEWPORT BOT)*yratio; 
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bot=VIEWPORT_BOT; 
i 


/f Point to video memory offset for top of Line: 
offset = top * 320 + column; 


‘f/f Initialize vertical error term for texture map: 
int tyerror=64; 


// Which graphics tile are we using? 
int tile=mapCxmazeJlymazel-1; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tilexs) 
*TMAGE_WIDTH+t ; 


‘/ Loop through the pixels in the current vertical 
‘/ line, advancing OFFSET to the mext row of pixels 
ff after each pixel is drawn. 

for Cint h=0; h<iheight; h++) ¢ 


‘/ Are we ready to draw a pixel? 
while (tyerror>=IMAGE HEIGHT) ¢ 


f/f If so, draw it: 
screenlLotfsetJ=textmapsltileptrd; 


if Reset error term: 
tyerror-=IMAGE_HEIGHT; 


f‘/ And advance OFFSET to next screen Line: 
offset+=320; 
} 


f/f Incremental division: 
tyerrort=height; 


// Advance TILEPTR to next Line of bitmap: 


tileptr+=320; 
} 


/f Step through floor pixels 
for (int row=bot+1; row<=VIEWPORT_BOT; row++) 7f 


ff Get ratio of viewer's height to pixel height: 
float ratio=(floativiewer_height/trow-100); 


// Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle}; 


if Rotate distance to ray angle: 
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int x = = distance * (sin(radians)); 
int y = distance * (cos(radians)); 


‘? Translate relative to viewer coordinates: 
Nt=EVIEW; 
¥t=yVieW; 


/f Get maze square intersected by ray: 
int xmaze x / G4; 
int y¥ymaze = y / 64; 


ff Find relevant column of texture map: 
int t = (Cintiy & Ox3f) * 320 + (Cint)x & Ox3f); 


‘f Which graphics tile are we using? 
int tile=floorlxmazellymazed; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE_HEIGHT#(tilex5) 
* IMAGE WIDTH+t; 


ff Calculate video offset of floor pixel: 
offset=row*320+column; 


‘f Draw pixel: 
screenloffsetJotextmaps(tileptrd; 


/f Step through ceiling pixels: 
for (row=top-1; row>=VIEWPORT_TOP; --row) 4 


// Get ratio of viewer's height to pixel height: 
float ratio=(float) (WALL _HEIGHT-viewer_height)/(100-row); 


// Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


‘/ Rotate distance to ray angle: 
int x = - distance * (sintradians)); 
int ¥ = distance * Ceostradians)}; 


ff Translate relative to viewer coordinates: 
K+=KXVIEH; 
¥F=¥VIeM; 


// Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymarze = y / 64; 
ff Find relevant column of texture map: 


int t = (Cintiy & Oxaf) * 320 + (Cintix & Oxat); 
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ff Which graphics tile are we using? 
int tile=ceilinglxmazelLymazel; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* 1TMAGE HEIGHT+(tilex5) 
*TMAGE_WIDTH+t; 


/f Calculate video offset of floor pixel: 
of fset=row*320+column; 


f/f Draw pixel: 
ecreenLoffsetl=textmapsLltileptrd; 


To run the program, go to the RAYCAST directory and type RAYDEMO. 
Youll see a fully texture-mapped view of the maze from an angle of 0 radians (see 
Figure 9-22). To see how the maze looks from other angles, type a number of 
radians from 0 to G,2 after the name of the program. Figures 9-23a through e 
show the maze from angles of 1, 2, 3, 4, and 5 radians. 

The texture-mapped maze drawn by this program is amazingly realistic, 
considering that it started life as little more than a trio of pwo-dimensional arrays 
and a PCX file containing 15 bitmaps. Such is the power of ray casting. Though 
the technique itself is fairly simple, it can be used to create vivid images very 
rapidly, as we ll see when we optimize our ray-casting code in chapter 13. 

We now have the core of a ray-casting engine thar could be used to produce a 
ray-cast game such as Origins Shadowcaster or Apogees Blake Stone and the 
Aliens of Gold. We can draw walls, Hoors, and ceilings, which is all the scenery 
generating that many state-of-the-art ray-casting games can do. In the next 
chapter, though, we're going to look at an alternate method thar can produce 
even more realistic images than this. This method will place us on the cutting 
edge of ray-casting technology and will pur us in a position to write a ray-casting 
engine that will rival the most advanced on the market. 

This new method is called Aeightmapping. 
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Figure §-22 A fully texture-mapped 
maze viewed fram an angie of 0 radians 
a6 Gepicted by the RAYDEMO program 














Figure 9-23a-e The maze as viewed Figure 9-23b 
from angles of 1, 2, 3, 4, and 5 radians, 
respectively 





Figure 9-23c Figure 9-730 





Figure 9-23e 


355 





Er | 1 ' - 
: eae 


=a! th 


ie 








he ray-casting method described in the last chapter produces 
vivid images, and can do so rapidly enough for high-speed 
animation if properly optimized. Burt it has a major drawback. It 
ties LS Into dd. single rype of SCONE, @& Midee of texture-mapped 





: eee blocks with texture-mapped floors and ceilings. Of course, that's 
the same type of scenery that weve been using throughout this book — indeed, 
that ctype of maze is at the very heart of the maze game genre. But even the most 
devoted maze game aficionado will eventually get sick of wandering down 
hallways that look like they were laid out on a sheet of graph paper. Before that 
happens, wed better learn to inject some variety into the design of our maze 
game graphics. 

Are there any ray-cast maze games on the market that defy this convention 
and feature Mazes that dont look like they Were drawn with a straight-edge and 
T square? Yes. At the time this book was written, the most notable of this elite 
company of games was Doom (see Figure 10-1), published by Id Software, the 
same company that introduced ray casting to the arcade game genre with 
Wolfenstein 3D. Doom features dazzlingly diverse maze graphics in which walls 
shoot out at all angles and have variable thicknesses. Not only do the walls in 
Doom defy the conventions of ray-cast maze games, but so do the floors, some of 
which rise to precipitous heights above the “ground.” In fact, unlike any ray-cast 
games published before it, Doom actually lets the player walk on top of the walls! 


GARDENS OF IMAGINATION 


? 





fi eid Readwipt © Bist 
Figure 10-1 A screen shot from Doom, published by id Software 


How does Doom do it? Does it use an advanced, hitherto unheard of form of 
graphics generation? Thars a difficult question to answer, since | dont know the 
secrets of the Doom programmers. All | know about Doom is what I can see on 
the screen of the computer when | play the game. However, | strongly suspect 
that Doom is using a technique known as herghtmapping. 


Block-Aligned Heightmaps 


The simplest form of heightmapping uses so-called block-aligned heightmaps. This 
isnt the method used by Doom, which achieves graphic effects that would not be 
possible if the heightmapping were strictly block aligned. However, the very 
simplicity of this method makes it an excellent introduction to heightmapping, 
so we ll talk about it first, before we move on to more advanced techniques. 

Up until now, we've assumed that the walls of the cubes that make up our 
mazes stretched from floor to ceiling. We couldnt see the tops of these walls 
because they were above our field of vision (and even if we set the viewers eve 
height to a value greater than the wall height, there would have been no tops to 
see, since our maze-drawing code contained no provisions for drawing these 
tops). In this chapter we'll drop that assumption. We'll allow walls to be any 
height at all, up to a preset limit. Well set this limit at 256 “height units,” since 
that will allow us to store the height of each wall section in a single byte of 
computer memory. And if the top of a wall is below the viewer's eye level, we'll 
draw the top, using the same techniques that we used in the last chapter to draw 
Hoors. 

Block-aligned heighthelds are much like the maze cubes that we used in 
the ray-casting engine in the last chapter, in that they are represented in the 
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computer as a two-dimensional grid of “maze squares.” The difference is that 
each square has an associated height value. While our earlier maze programs have 
treated the Hoor of the maze as though it were fat, in a heightmapped maze each 
section of Hoor can have a different height from the sections around it. And a 
maze square that is higher than the the squares surrounding it will have “sides,” 
which form the walls of the heightmapped maze. Because the height of the floor 
squares 1s variable, so ts the height of the walls. Walls can be short enough to trip 
over or too tall to climb. In a game based on such a heightmapped ray-casting 
engine, short walls can be used to represent stair steps, tables, or fences, Tall walls 
can represent barriers or towering obelisks. 


The floorheightl! Array 

We'll store the height values of the maze squares in a 16 by 16 array of unsigned 
integer values, just like the ones we used in the last chapter to store bitmap values 
for the Hoor, ceiling, and walls of the maze. We'll still maintain the floor and wall 
arrays, just as we did before (though for now we'll drop the ceiling array, to 
simplify the code). Burt this time well add an array called floorberght/! to store the 
height values. Here's the floorberghr!/ array for the simple heightmapping demo 
that well develop over the next few pages: 


map type floorheight={ 
{270,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20), 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20, 0, 0,20,20,20,20,20,20,20,40,60,80,100,120,120}, 
{70, OG, 0,20,20,20,20,20,20,20,20,20,20,20,120, 120}, 
{20, 0, 0,20,20,20,20,20,20,20,20,20,20,20,120,1201), 
{20,20,20,20,20,20,20,20,20,20,40,60,80,100,120,120}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,60,60,60,60,40,20,20,20,20,20,20,20}, 
{20,20,20,20,60,100,100,100,60,20,20,20,20,40,20,20}, 
{20,20,20,20,60,100,150,100,60,20,20,20,40,40,20,20}, 
{20,20,20,20,460,100,100,100,60,20,20,40,40,40,20,20}, 
{20,20,20,20,60,60,60,60,60,20,20,20,20,20,20,20}, 
{(20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20} 

+} 


Youll notice that most of the “floor squares” in this map have been set at a height 
of 20 units. By making 20 units the “normal” Hoor height throughout the maze, 
we can create depressions in the Hoor as well as walls. For instance, you may have 
noticed that some of the floor squares in the middle left portion of the array have 
a value of 0. These lowered floor segments, arranged in a rectangular relationship, 
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will be used to create a swimming pool in the maze. A swimming pool? Be 
patient. Youll get a look ae this unusual maze convenience in a moment. 


The walll] and flort] Arrays 


Here are the wall// and flor// arrays that we'll be using: 
map type wall={ 


C3, Se 3r Se Se Fe Se Fe a Jy oe Dy = ay Dy at, 
apc ap ee ee eee, eee i ee 
{ 5, 5, 5, 5,5) 5, 5, 5, 5, 5, 5;°5, 5; 5, 55 St, 
1 3,035, °3, 5,095 3,8, 5; 5, Sp 0S,-5, 55-555 ,-53) 
1 9, 3e 36 Je Fy Fe Sp Se Sp Se By Je Se Dy Oy ST, 
.. So ee poe See oe ep Se ate, She ee Se he, 
1 ga ee ay See eet age Gear Big ee ae 
14,03) 3, 3, 3, 3, 5, 5; 5, 57 Sy 3, Sy 3, Sy SF, 
{T4, 3, Sr Jp Sy Je Fp Fe Sp Se 34 Fy Dy Sy Dy ST, 
CBee eee oe Ste ey Sie Sy ae Be eae 
{ 3, 3) 3,3; 12, lf,it; eple, op 3, 3p 5, 5555-5), 
{ 3, 3, 3, 3,1¢,12,12,12,12, 35, 5, 35, 5, 5, 5, 53, 
f 5 he Se. SGT a ee Ss, 5. Se 5, 5,5. SH. 
£5, 5, 5, 5,12,12,12,12,12, 5, 5; 5, 5, 5, 5, 5k, 
{ 3, 3, 3, 5,72; ie 12,12, 12, 5, 5,5, 55 5, 5,53; 
PSS Sp oe ae Be ey Se ee Op Ss Se Se Se Be 

I; 

map type flor= 
tf 3y 9, Je Je Je De De Se Fe Fe Fe Ie Fy Fy By ST, 
cg ae ae gs Seopa oleae aig alee ies on 
{ 555, 5, 5,55 5, °5).55- 5.555555, 5).:55- 55 - Sk, 
f Bp dy Se Op De Sp oe Op Se oe Jeo 3, 5, 5p 3, 5, 
ee Dre ete Pte Pate: FON Wapiti Mapas ein Semi Bee Pe Yeas ee: era 2 oe 
ie Pray 6 ps ame Peng JP te Page Rae ebm SR et ls Fede Pei ete ft 
{ 5,10,10, 5,5, 3,25, 3S, 553, 5,5, Sy 5, 5, 5h, 
{ 5,10,10, 35, 5, Sy 3p Sp Se 3p 3p By By De Jy 3, 
toe ees Aa eee oni ec is Bie i ai ae 
{ 5, 5, 5,:5, 3, 5,95, 5, 3, 3) 5,5, 33 5, Sy Sh, 
£3, 3, Sp 3,715,735, 15,15,135- 3¢ 3p 3p By Se 3p Sy 
3S, 9, SPA Saas ae geo a Soo So Se 
i Be Spa ig A ae ee ae eae ele aie aie epee ede 
{ 3, 5, 5, 35,13,135,13,13,135, 37 37 37 Se 3, 3, 5), 
{5, 5, 5, 5,13,13,13,13,13, 5, 5, 5, 5, 5, 5, 5}, 
£5, 5, 5:5, 5, §,-5, 5, 5,5, 5; S, 5,5, 5, 5} 

I; 


Although we used both of these arrays in the last chapter, they will take on a 
5 ightly different meaning in the block- aligned heightmapped version of the 
draw mazel) function. The Hor!] array values will not only indicate which tiles 
are to be mapped onto the corresponding sections of Hoor, but which tiles will be 
mapped onto the tops of walls (which are now simply raised sections of floor). 
The wail!/ array values now tell us what ules will be mapped onto the sides of 
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raised floor sections. In some cases, these “half-height walls’ may be only a few 
pixels high, sO) only a small portion of the tile will actually he mapped Ont them. 
In other cases these walls may soar as much as 256 pixels above the surrounding 
Hoor, requiring tiles larger than the 64-pixel-tall tiles we used in the last chapter, 
To accommodate such walls, We could include larger tiles 1 In Our tile set (though 
it would be difficult to ft a 256-pixel-tall tile into a 320 by 200 PCX file), or we 
could write the wall-texturing code so that it starts again at the top of the tile 
when it reaches the bottom. In this chapter we'll do neither. In the one case 
where we use a wall that rises more than 64 pixels above the surrounding Hoor, 
We ‘II simply let the wall- “texturing routine continue into the tile positioned 
vertically beneath the wall tile indicated in the mail|} cll Tat; ta provide al vivid 
illustration of the way in which the wall-rexcuring routine works. 

(Note that a wall that rises # pixels above the surrounding Hoor is not 
necessarily the same thing as a wall » pixels tall. If a wall thar is, say, 128 pixels 
tall is surrounded by Hoor squares that are 96 pixels tall, then only the top 32 
pixels of the wall will need to be texture mapped, not the full 128 pixels. The rest 
will be hidden by the surrounding Hoor.) 


Heightcasting 


Casting for raised sections of floor in a block-aligned heightmapped maze — a 
" ij a : ot r " n a 
Process that might he called heightcasting =—— 15 no ditterent trom Casting for 
walls in a hxed-Hoor-height maze such as the one in the last chapter. 50 we'll 
develop our heightcasting routines by taking the wallcasting code from the last 
chapter and altering it so that it casts for changes in oor height instead of walls, 
The code for drawing walls and floors will need to be altered too, but we can still 
Lise the wall and Hoor texturing code from the last chapter as ad template for 
creating these parts of the function. Since the majority of the code in the block- 
aligned heightmapped version of the draw_maze() function will be identical to 
that used in the version of the function we developed in the last chapter, I'll only 
explain the differences before | show you the function in its entirety. 
One difference is in the prototype of the function, which has changed yet 

again: 
void draw_maze(map_type wall,map_type floor, 

map type floorheight,char far *screen, 

int xview,int yview,float viewing_angLe, 

int viewer_height,char far *“textmaps); 


The ceiling parameter has now been replaced by the floorheight parameter, which 
is a pointer to the floorbeight/! array. This prototype is in the fle BLOKCAST.H 
in the HEMGHT directory. The function itself is in the fle BLOKCAST.CPP, in 
the same directory, 
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We'll add a new constant declaration at the head of that file: 
const GRIDWIDTH=14; 


The GRIDWIDTH constant tells us the width (and breadth) of the maze in 
Hoor squares, We havent bothered introducing such a constant in earlier chapters 
since its only useful in bounds checking, and we've been carefully placing walls 
around the perimeter of the maze so that bounds checking isnt necessary. With a 
heightmapped maze, however, placing walls around the boundary of the maze 
doesnt do Ls much good, since the wallcasting code will rich longer come to a halt 
when it reaches a wall. In this maze, walls can be visible past other walls (due to 
height variations), so we ll have to cast until we reach the limits of the maze grid, 
as dehned by GRIDWIDTH. (This need to cast all the way to the edges of the 
map can slow down the ray casting a bic when the map is large and the viewer ts 
looking toward the more distant end. An obvious optimization is to find a way to 
cut the casting short when no more walls are going to be visible, though finding 
such Al optimization isnt necessarily cll trivial task. Since the heightmapping code 
wont be used i 1th the optimized rd casting engine developed i IT] chapter 12, [’ I 
take the lazy way out and leave this optimization as an exercise for the reader.) 


How High the Viewer? 


Because the Hoor Celt) DO take ol TLh’ height, the first thing the function will need 
to do is find out how high the Hoor is directly under the viewers teet. To find 
out, well calculate the maze grid coordinates on which the viewer is standing by 
dividing the xview and ywiew parameters (which store the viewers fine 
coordinates within the maze) by 64: 

int xmaze=xview/64; 

int ymaze=yview/64; 

We can then consult the fleerbeight// array to determine the height of this floor 
suatre: 


currentheight=floorheight(xmazellymazed; 


We'll base the code that follows on the assumption that the wiewer_height 
parameter passed from the calling routine represents the height of the viewer's 
eyes above the floor level, though we could just as easily assume that 
wiewer height represents the height of the viewers eyes above a base level of 0. 
Since it will also be useful to us to know the viewer's height over such a base level, 
we ll calculate it by adding wiewer_height wo currentheight: 


int vheight=viewer_heightt+tcurrentheight; 
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Well then set up to cast a ray across the maze grid exactly as we did in the last 
chapter, except that we ll initialize a variable called lasttop, the purpose of which 
will be obvious In a moment: 


Lasttop=VIEWPORT_BOT; 


Because well be casting for walls all the way to the edge of the maze grid, we 
can no longer use an open-ended for{) loop. Instead, well use a whele() loop that 
will watch for either the xmaze or the ymaze variable (which represent the maze 
grid coordinates of the next square to be examined) to run off one of the edges of 
the Maa: 


while((xmaze>=0)88( xmazecGRIDWIDTHIGE( ymaze>=0) 
Ea(ymaze<GRIDWIDTH)) { 


We'll also need to nest a second loop inside this one, to perform the actual 
casting. The outer loop, which we just initialized, will cause this inner loop to be 
repeated again and again until the edge of the maze ts reached. (Remember that 
we no longer stop casting when we hit a wall.) The inner loop will also be 
structured as a whéle() loop that will terminate when it reaches the edge of the 
maze: 


while((xmaze>=0)8E( xmaze<GRIDWIDTHIE&( ymaze>=0) 
SeCymaze<GRIDWIDTH)) f 


(This use of two nested loops with the same terminal condition ts not especially 
efiicient and will slow down the code. Readers are encouraged to find ways to 
make these loops run more efficiently.) 


Changes in Floor Height 


We then proceed to cast the ray against the x and y grid lines exactly as we did in 
the last chapter. Instead of looking for walls, though, we'll look for changes in 
Hoor height. The current floor height ts stored in the integer variable 
currenthetght, so all we need to do to find such a change is compare this value 
with floorheight/xmaze/|ymaze] for the maze square that we're examining: 


if (floorheightCxmazel]lymazel] '= currentheight) break; 


Well need to use this line twice: once in the code thar tests for collisions with a 
wall on an x grid line, and once in the code that tests for collisions with a wall on 
ay grid line. This will cause the inner loop to terminate when a change in Hoor 
height is found. 

When such a change is detected, we can find the distance from the viewer to 
that change exactly as we found the distance to walls in our earlier ray-casting 
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program. Now, however, the height of the wall will be variable — and the wall 
may not even be facing toward us. Well worry about these problems in a 
moment. For now, we need to determine the y position on the video display at 
which the bottom of the wall is to be drawn. 

We can accomplish this using the similar triangles method that we introduced 
in the last chapter. (If you don’t recall how this method works, you might want to 
thumb back to that chapter and give yourself a brief refresher course.) In Figure 
10-2 youll see the familiar pair of nested triangles from the last chapter. At that 
time, we knew the lengths of the lines labeled a, c, and C, and needed to find the 
length of line A, the distance from the viewer's position to the Moor pixel visible 
through the sereen line currently being cast. This time, we know the lengths of 
A, C, and a, and need to find the length of ¢, the distance from the center of the 
display (represented by the constant VIEWPORT_CENTER) to the screen line 
where the bottom of the wall will appear. The law of similar triangles tells us that 
the following relationship exists between these lines: 

c/C = a/A 


Thus we can find the length of ¢ with the following expression: 
c = a/A*C 


In the function that we're developing, the length of @ is represented by the 


constant VIEWER_DISTANCE and the length of A by the integer variable 





Figure 10-2 The inner triangle, representing the distance from the wewer to the screen, i$ 
“similar” in a geometric sense to the outer triangle, representing the distance from the 
viewer to the wall 
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distance. Getting the length of C takes slightly more work. The height of the 
viewer above the Hoor is contained in the 1 integer variable mewer_ height, and the 
height of the viewer above a base level of 0 is contained in the integer variable 
ubeight. However, what we really need | Is the height of the VICWEL above the Hoor 
level at the base of the wall, which is stored in the integer variable currentheight. 
To get the viewers height above this level, well subtract currentheight trom 
vheight. In the actual function, we'll break the process into two steps. First we'll 
divide VIEWER_DISTANCE by aistance and put the result in the Hoating point 


variable natia: 


float ratio=(float)VIEWER_DISTANCE/ distance; 


Then well multiply the viewers height by rate to get the distance from the 
viewer's eye level to the row of pixels on screen where the bottom of the wall will 
be drawn and store the result in the integer variable sereendeptir: 


int screendepth=ratio*(vheight-currentheight) ; 


We can translate this into an absolute screen y coordinate by adding screendeprh 


to VIEWPORT _CENTER and storing the result in the integer variable bor: 
bot = VIEWPORT_CENTER + screendepth; 


Before we proceed to draw the wall, we must check first to see if there tsa wall. 
If we've reached this point in the code, we know that the ray-casting loop has 
terminated, but we dont know wy it terminated. In fact, it can terminate for 
two different reasons: if a change in Hoor height has been found or if the edge of 
the maze grid has been reached. In the latter case, we dont need to draw 
anything, so we test to make sure were not past the edge of the maze before we 
proceed to draw cb. wall: 


af ((xmaze>=0)88(xmaze<GRIDWIDTH)&E 
Cymaze>=O)}88Cymaze<GRIDWIDTH)) ¢ 


If we arent at the edge of the maze, then a change in floor height must have 
been detected. So that we dont have to keep referencing the floorheight// array 
(which may waste CPU time on array indexing), we'll store the new height of the 
Hoor in an integer variable called (what else?) newheight: 


newheight=floorheight(xmazelLymaze; 


Next we need to know the height of the wall that were going to draw — not the 
visual height, adjusted for perspective, but che actual height in height units. This 
is simply the difference between the height of the floor just before the change 
(stored in cvrrentherght) and the new height of the Hoor (which we just stored in 
newheight). We'll store the height of the wall in the integer variable wallheighr: 


a all 


a 
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wal lheight=newheight-currentheight: 


There are two ways in which the height of the floor can change from one Hoor 
square to the next, in the direction that the ray is traveling: It can go up or it can 
go down. [fit goes up, then the wall is facing us and we need to draw tr. If it SOE 
down, then the wall is facing away from us, and we dont need to draw ir (see 
Figures 10-3a and b). Se before we can do anything else, we need to check to see 
if the value of wallhetehtis positive (meaning that the height of the Hoor has gone 
up) or negative. If it is negative, we need to set the value of an integer variable 
called tap to be equal to the value of bot. We'll see why in a moment. 


if (wallheight<0) top=bot; 

lf wallbeight isnt negative, we draw the wall: 
else { \\ Draw the wall 

The code for drawing the wall is much like the texture-mapped wall-drawing 
code that we developed in the last chapter, except that the height of the wall ts 
now variable. We begin by calculating the perspective-adjusted height of the wall 
and storing it in the integer variable visheight: 
int visheight = (float)VIEWER_DISTANCE * wallheight / distance; 

We can find the y position on screen of the top pixel in the wall by subtracting 
wisheight trom ber and storing the result in an integer variable called tap: 
top = bot - visheight; 
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Figure 10-3a iF the floor height Figure 10-3b if the floor helaht 


increases in the direction that the ray decreases in the direction that the ray is 
traveling, the wall formed by the raised traveling, the wall formed by the lowered 
surface is facing toward the viewer surface is facing away fram the viewer 
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We subtract visheight from er rather than adding it because y coordinates on the 
screen grow smaller as we move upward. Thus, the y coordinate of the top of the 
wall is lower than the y coordinate of the bottom of the wall. 

Before we can draw the wall, we must clip it. In the previous chapter, we 
clipped the top and bottom of the wall against the top and bottom of the 
viewport. Now, however, we must also clip the bottom of the wall againsr the cop 
of any walls thar lie between it and the viewer, since these walls would obscure 
the viewer's view of the wall (see Figure 10-4). Instead of clipping dor against 
VIEWPORT_BOTTOM, as we did in the last chapter, we'll clip it against the 
integer variable dasttap, which we set equal to VIEWPORT_BOTTOM at the 
beginning of the function. When we finish drawing the wall, however, we'll reset 
lasttop to the y position of the top of the wall, so that any walls further along the 
path of the ray will be clipped against the top of this wall (or any taller walls 
encountered in the interim), 

(Actually, this isn't precisely what will happen. Although we need to save the y 
coordinate of the top of the wall in Jasttop for other reasons, we'll actually need to 


clip the next wall against the top of the backfacing wall on the other side of the 





Figure 10-4 The raised floor square at position A 
obscures the viewer's view of the bottam af the wail 
created by the raised floor square at position B. Thus we 
must clio the bottom of wall B against the highest point 
In floor square A 
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elevated Hoor square, as you can sec from a close look at Figure 10-4 note the 
dotted lines, Thats why we included instructions earlier that will save the top y 
coordinate of backward-facing walls in the variable top, should wallheight be 
negative, Alchough backward-facing walls aren't drawn, the y coordinates of their 
tops will be placed in dasttap ac the end of the outer casting loop so that more 
distant walls can be clipped against therm.) 

The actual drawing of the wall is done exactly as we did it in the last chapter, 
except that the height of the wall is stored in the variable wallberght and only that 
many pixels from the top of the corresponding texture tile will need to be 
mapped onto the wall, (As noted earlier, should the wall be taller than the tile 
assigned to it, the texture mapping code will proceed into the tile positioned 
beneath it in the PCX fle — or into the garbage beyond the end of the file, 
should the tile be in the bottom row.) 

In the last chapter, once the wall was drawn, we drew floor pixels trom the 
bottom of the wall to the bottom of the viewport, We'll do the same thing here, 
except that instead of drawing to the bottom of the viewport we'll draw floor 
pixels from the bottom of the wall to the top of the last wall drawn, the y 
coordinate of which is in éesttop. (Initially, as we noted above, dasttop will be set to 
the botram of the viewport.) We must watch for an additional possibility here, 
though: The foor pixels may be on an elevated oor square that places them 
above the viewers line of sight (see Figure 10-5), If this happens, we must not 
draw the floor pixels, since the top of the floor square isn't visible. We can 
determine if this is the case by checking to see if ber is below the middle of the 
viewport (that is, has a y coordinate value greater than VIEWPORT_CENTER): 


if (bot > VIEWPORT_CENTER) { 


The only ditterence in the Hoor-drawing code from that used itn the last 
chapter is in the beginning of the loop: 


for Cint row=bot+1l; row<lasttop; row++) f{ 


Now, for reasons explained above, we cast to the top of the last wall drawn rather 
than all the way to the bottom of the viewport. 

Once the Hoorcasting is done, we only need to change a few variable values 
before we terminate the outer ray-casting loop, First we set currentheight to the 
new Hoor height: 


currentheight=newheight; 


We also need to set dasttop to the height of the top of the wall. However, we must 
make sure that the current wall isnt a short wall thats completely obscured by a 
visually taller wall closer to the viewer. In that case, we'll want to leave /asttop 
equal to its previous value: 
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Figure 10-5 if the too of an elevated floor square is above 
the viewer's line of sight (that is, the center oF the screen, 
the floor pixels on top of the square will not be visible 


if (top<lasttop) Lasttop=top; 


And that’s the end of both the ray-casting loop and the latest version of the 
draw _maze() function. 


The Block-Aligned draw_maze() Function 


The complete text of the block-aligned heightmapped @raw_maze() function 
appears in Listing 10-1. 





| Listing 10-1 The block-aligqned draw_mazel) function 


// BLOKCAST.CPP 

if 

// Function to draw texture-mapped walls, floors and 
‘f ceilings using ray casting. 

ff Written by Christopher Lampton for 

‘/ Gardens of Imagination (Waite Group Press). 

ii 


CoMtrand on nu? pape 
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COM rine Penet pretirE Mage 
Finclude <stdio.h> 
Finclude <math.h> 
Hinclude “blokcast.h" 
Finclude “pex.h" 





f/ Constant definitions: 


const WALL_HEIGHT=44; ff Height of wall in pixels 
const VIEWER DISTANCE=192; ff Viewer distance from screen 
const VIEWPORT_LEFT=Q; // Dimensions of viewport 


const VIEWPORT _RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT _BOT-VIEWPORT_TOP; 

const VIEWPORT_CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/?2; | 
const GRIDWIDTH=16; 


void draw_maze(map_type wall,map_type floor, 
map_type floorheight,char far *screen, 
int xview,int yview, 
Tloat viewing_angle,int viewer_height, 
char far ™ textmaps) 


/* Draws a@ ray cast image in the viewport of the maze represented 
‘/ in array MAPCI, as seen from position XVIEW, YVIEW by a 

‘/ viewer looking at angle VIEWING_ANGLE where angle O is due 

// north. (Angles are measured in radians.) 


{ 
‘/ Variable declarations: 
int sy,offset; // Pixel y position and offset 
float xd,¥d; /f Distance to next wall in x and y 


int grid_x,grid_y; ‘/ Coordinates of x and y¥ grid Lines 
float xcross_x,xcross_y; // Ray intersection coordinates 
float yoross_x,ycross_y; 

unsigned int xdist,ydist; // Distance to x and y grid Lines 
int distance,realdistance; // Distance to wall along ray 
int tmcolumn; ‘/ Column in texture map 

float yratio; 

int currentheight; // Height of current floor block 

int newheight,wallLheight; 

int heightchange; 

int top,bot,lasttop; 

float x,¥; 


/? Loop through all columns of pixels in viewport: 
for Cint columm=VIEWPORT_LEFT; columm<VIEWPORT_RIGHT; column++) f{ 


// Get viewer's initial coordinates: 
int xmaze=xview/ 64; 


int ymaze=yview/ 64; 


ff Get height of floor under viewer: 
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currentheight=floorheightCxmaze]Lymazel; 


‘/ Calculate height of viewer above base Level: 
int wheight=viewer_height+currentheight; 


// Calculate horizontal angle of ray relative to 
ff center ray: 
float column_angle=atan( (float) (column-160) 

/ WIEWER_DISTANCE); 


ff Calculate angle of ray relative to maze coordinates 
float radians=viewing_angletcolumn_angle; 


// Rotate endpoint of ray to viewing angle: 
int x2 = -1024 * Csin€radians)); 
int ¥2 1024 * (costradians)): 


/* Translate relative to viewer's position: 
x2+=XVIEOW; 
ye+=yview; 


ff Initialize ray at viewer's position: 

X=xV1eGW; 

yoyview; 

ff Find difference in x,¥ coordinates along ray: 
int xdiff=x2-xview; 

int ydiff=y2-yview; 


‘i Cheat to avoid divide=-by<zero error: 
if (xdiff==0) xdiff=1; 


‘i Get slope of ray: 
float slope = (floatiydiff/xdiff; 


‘/ Cheat (again) to avoid divide=-by=zero error: 
if (slope==0.0) slope=.0001; 


Lasttop=VIEWPORT_BOT; 
‘i Cast ray from grid Line to grid Line: 
while((xmaze>=0)88(xmaze<GRIDWIDTHIEE( ymaze>=0) 
EeCymaze<GRIDWIDTH)) { 
// Repeat casting Loop until edge of maze is found: 
while((xmaze>=0) 28 (xmaze<GRIDWIDTHIEE( ymaze>=0) 
fa(ymaze<GRIDWIDTH)) f 


‘i Tf ray direction positive in x, get next x grid Line: 
if (xdiff>0) grid_x=(Cintix & OxffcO)+64; 


‘f If ray direction negative in x, get last x grid Line: 
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else grid_x=({int)x & OxffcO) = 1; 


‘f If ray direction positive in y, get next y grid Line: 
if Cydiff>0) grid_y=(Cintdy & OxffcO) +44; 


/f If ray direction negative in y, get last y grid Line: 
else grid_y=(Cintiy & OxffcO) - 1; 


// Get x,y coordinates where ray crosses x grid Line: 
xeross K=grid_x; 
xeross_ y=y+slope*(grid_x-x); 


// Get x,y coordinates where ray crosses y grid Line: 
yeross x=x+(grid_y-y)/sLlope; 
¥oross  y=grid_y; 


‘/ Get distance to x grid Line: 
xd=xcross x-x; 

¥d=xcross_y-¥; 
xOst=sqrtt(xd™xd+yd"ya?) ; 


ff Get distance to y grid Line: 
xd=ycross_x—x; 

¥d=ycross_y“¥; 
ydist=sqrt(xd*xd+yd*yq) ; 


ff If x grid Line is closer... 
if (xdist<ydist) f 


/f Calculate maze grid coordinates of square: 
umaze=xcross_x/64; 
ymaze=xcross_y/64; 


ff Set x and y to point of ray intersection: 
M=KCPOSS x, 
Y=KCPOSS_ ¥,; 


// Find relevant column of texture map: 
tmeolumn = Cintdy & Oxst; 


// Is there a maze cube here? If so, stop Looping: 

if (floorheight(Cxmazellymazeld != currentheitght) break; 
} 
else { // If y grid Line is closer: 


ff Calculate maze grid coordinates of square: 
xmaze=ycross_x/44> 
ymMaze=ycross_y/64; 


// Set x and y to point of ray intersection: 
K=yYCross_x; 
Y=YCross_y; 
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/f Find relevant column of texture map: 
tmcolumn = (intix & Ox3f; 


‘if Is there a maze cube here? If so, stop looping: 
if Cfloorheight(xmazellymazel '= currentheight? break; 
} 


} f/f End of inner casting Loop 


// Get distance from viewer to intersection point: 
xd=x-xview; 

y¥d=y-y¥vView; 

realdistance=(long)sqrt(xd*xd+yd*yd) ; 
distance=(Long)realdistance*cos(coLumn_angle); 

if (distance==0) distance=1; 


‘? Calculate bottom of wall on screen: 

float ratio=(float)VIEWER_DISTANCE/distance; 
int screendepth=ratio*(vheight=currentheight); 
bot = VIEWPORT_CENTER + screendepth; 


if ((xmaze>=0)88( xmaze<GRIBWIDTH)&E 
(ymaze>=Q)ER(ymaze<GRIDWIDTH)) ¢ 


newheight=floorheightLxmaze]Lymazel; 
wal Lheight=newheight-currentheight; 


if Cwallheight<=0) top=bot; 
else { 


ff Calculate visible height of wall: 
int wisheight = (floatdJVIEWER_DISTANCE * wallheight / distance; 


ff Calculate top of wall on se¢reen: 
top = bot — visheight; 


ff Initialize temporary offset into texture map: 
int t=tmcolumn; 


ff If top of current vertical Line is outside of 
‘/ wiewport, clip it: 
int dheight=visheight; 
int theight=wallheight; 
yratio=(float)wallheight/visheight; 
if (top < VIEWPORT_TOP) f 
dheight==(VIEWPORT_TOP = top); 
t+=Cint)((VIEWPORT_TOP-top)*yratio)*320: 
Theight <= (CVIEWPORT_TOP-top)*yratio?}; 
top=VIEWPORT_TOP; 
3 
if (bot > lasttop) { 
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dheight -= (bot - Lasttop); 
iheight -= (bot - Lasttop)*yratia; 
bot=lasttop; 
} 


if Point to video memory offset. for top of Line: 
offset = top * 320 + column; 


ff Initialize vertical error term for texture map: 
int tyerror=i1height; 


fi Which graphics tile are we using? 
int tile=walllxmazeJlLymazeJ—1; 


‘/ Find offset of tile and column in bitmap: 

unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tilexs) 
*IMAGE_WIDTH+t; 

‘/ Loop through the pixels in the current vertical 

ff Line, advancing OFFSET to the next row of pixels 


ff after each pixel is drawn. 
for (int h=O; heiheight; het) f{ 


ff Are we ready to draw a pixel? 
while (tyerror>=iheight) ¢ 


‘f If so, draw it: 
screenLoffsetl=textmapsltileptrd; 


/*# Reset error term: 
tyerror-=theight; 


ff And advance OFFSET to next screen Line: 
offset+=520; 
} 


ff Incremental division: 
tyerror+=dheight; 


// Advance TILEPTR to next Line of bitmap: 
tileptr+=320; 


} f/f End of fort) Loop 
+ f/f End of if 
} f/f End of if 
if (bot > VIEWPORT_CENTER) f 


// Step through floor pixels: 
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for (int row=bott+1; row<lasttop; row++) ¢ 


ff Get ratio of viewer's height to pixel height: 
float ratio=(float) (vheight=currentheight) 
/ €row-VIEWPORT_CENTER); 


ff Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


ff Rotate distance to ray angle: 
int px = - distance * (sintradians)); 
int py = distance * (cos(radians)); 


‘ff Translate relative to viewer coordinates: 
pxt=xview; 

py+=yview; 

// Get maze square intersected by ray: 

int xmazes = px / 64; 


int ymazes = py / 64; 


f/f Find relevant column of texture map: 
int t = (Cintipy & Ox3f) * 320 + (Cintipx & Ox3f); 


ff Which graphics tile are we using? 
int tile=floor(xmazeslCymazesd; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tilexs) 
*IMAGE_WIDTH+t; 


‘i Calculate video offset of floor pixel: 
offset=row*320+column; 


‘? Draw pixel: 
screenLoffsetJ=textmapsltileptrd; 


} /f End of floor loop 
} ff End of 70) 
currentheight=newheight; 
if (topelasttop) Lasttop=top; 
if (lasttop>VIEWPORT_BOT) Lasttop=VIEWPORT_BOT; 


+ f/f End of outer casting whilet) Loop 


} // End of column for() Loop 
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The BLOKDEMO Program 

To demonstrate this latest maze-drawing function, well write a short calling 
program called BLOKDEMO that will use draw_maze() to draw a view of a 
heightmapped maze. This calling program will use the three arrays shown earlier 
in this chapter. As in the demo programs in the last chapter, it will read a 
parameter from the command line thar represcnes the number of radians relative 
to due north that the viewer should be facing. It will also check for a second 
parameter representing the height of the viewer above the floor, so that you can 
look at the maze from both high and low vantage points. This height should be 
in the range | to 255, though you can try other values to see what sort of results 


you can obtain. 
The text of the BLOKDEMO program appears tn Listing 10-2. 





=e Listing 10-2 The BLOKDEMO.CPP program 


/* BLOKBDEMO. CPP 

if 

// Calls ray=-casting function to draw view of 
‘if block-aligned height fields. 

fi 

ff Written by Christopher Lampton for 

/‘/ Gardens of Imagination (Waite Group Press) 


Ainclude <stdio.h> 
finclude <dos.h> 
finclude <conia.h> 
Finclude <stdlib.h> 
Finclude <math.h> 
finclude “screen.h" 
Finclude “pex.h" 
Hinclude "“blokcast.h" 
ff#include "“bitmap.h" 


const NUM_IMAGES=15; 
pox struct textmaps,highmaps; 


map_type walle=f 
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map type floorheight=t 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
(70, 0, 0,20,20,20,20,20,20,20,40,60,80, 100,120,120}, 
(20, 0, 0,20,20,20,20,20,20,20,20,20,20,20,120,120), 
{20, 0, 0,20,20,20,20,20,20,20,20,20,20,20,120,120}, 
{20,20,20,20,20,20,20,20,20,20,40,60,80,100,120,120}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20}, 
{20,20,20,20,60,60,60,60,60,20,20,20,20,20,20,20}, 
{20,¢0,20,20,60,100,100,100,60,20,20,20,20,40,20,20}, 
{20,20,20,20,60,100,150,100,60,20,20,20,40,40,20,20}, 
{20,20,20,20,60,100,100,100,60,20,20,40,40,40,20,201, 
{20,20,20,20,60,60,60,60,60,20,20,20,20,20,20,20}, 
{20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20) 

}; 


float viewing_angle=0; 
int wiewer_height=32; 
int xview=6"64446 : 
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comninned Pony mretions pape 
int yview=6*64; 


void maintint argc,char* argvLl]) 
{ 
// Read arguments from command Line if present: 
if Carge>=2) viewing_angle=atoflargvl1]); 
if Carge>=3) viewer_height=atoftargv[2]); 


// Load texture map images: 
if CloadPCX("images.pex",&textmaps)) exit(1); 
if CloadPCX("highmaps.pcex",Shighmaps)) exit(1); 


// Point variable at video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


/* Save previous video mode: 
int oldmode=*(int *)MK_FP(0x40,0"49) > 


‘/ Set mode 13h: 
setmode(Qx135); 


ff Set the palette: 
setpalette(textmaps.palette); 


// Clear the screen: 
cletsereen) ; 


‘/ Draw a ray~-cast view of the maze: 
draw_maze(wall,flor,floorheight,screen, 
xView, ¥view, Viewing _angle,viewer_height, 
textmaps. image); 


ff Wait for user to hit a key: 
while C'kKBRIEC)): 


‘i! Release memory 
delete textmaps.image; 
delete highmaps. image; 


// Reset video mode and exit: 
setmode(oldmode) ; 


To run the program, go to the HEIGHT directory and type BLOKDEMO, If 
you dont type any parameters on the command line, the view will default to 0 
radians and a height of 32 units. You'll see the image depicted in Figure 10-6: a 
pair of staircases leading up to a platform. Want to see the platform from a higher 
angle? Hit a key to end the program and type BLOKDEMO 0 150. This will 
elevate your viewpoint to 150 height units above the Hoor (which is already 20 
units tall), as shown in Figure 10-7. 
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Figure 10-6 The view due north fram Figure 10-7 The view from 150 height 
the center of the héightmapped maze units above the floc 


Remember that swimming pool | mentioned earlier? Irs right behind you, Do 
an abour face by typing BLOKDEMO 3.14 64 to rake a look at ir (or just check 
out Figure 10-8). Another point of interest is the pyramid-like structure to the 
west. Take a look at it by typing BLOKDEMO 4.7 192 (see Figure 10-9). 

Now youre on your own. Experiment with various angles and heights. (Don't 
overlook that structure in the northwest corner thar looks vaguely like the 
Batplane.) When you get tired of looking around, come back and read the rest of 
this chapter, where well discuss methods tor making heightmapping even more 


versatile and useful, 


Heightmapped Ceilings 

It youd like ta extend this svstem, an obvious place to start is by heightmapping 
the ceilings as well as the Hoors. Just as the floor in a heightmapped maze can go 
up, so the ceiling can come down. This can be used to produce interesting 
effects, such as stalactite-like descending structures and skylights (which would 
simply be raised portions of ceiling with brightly colored graphics tiles mapped 


onto them), 





Figure 10-8 Not many mazes have their Figure 10-9 The pyramid wewed froma 
OWT SWIMMING poos lofty perch 
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One problem this introduces is hidden surface removal. You must take care 
not to draw a distant portion of raised Hoor that would be blocked by a nearer 
section of lowered ceiling, or vice versa. This means that you'll need to draw the 
Hoor and ceiling together, checking each block of floor and the block of ceiling 
above it for height changes and drawing those changes before moving on to more 
distant blacks. Youll also need to be careful that you don't lower the ceiling to a 
level below that of the floor (though lowering the nwo to the same level, thus 
forming a wall, shouldnt be a problem). 


Tiled Heightmaps 

Block-aligned heightmaps are simple to create, require relatively little memory to 
store, and can be rendered on the display fairly rapidly, if not quite as rapidly as 
the single-height maze maps in the last chapter. But block-aligned heightmaps 
suffer from an obvious limitation: They only allow us to elevate square sections 
of Hoor. Thus the walls in a maze rendered with this technique are srill 
orthogonal — aligned with the maze grid — and have the same minimum 
thickness as the maze cubes we used in earlier chapters. They allow us to create 
multilevel mazes, but they dont free us from the tyranny of the maze grid. 

The ideal heightmap would not be block-aligned but pixel-aligned — that is, it 
would allow every Hoor pixel to have a different height from the pixels around it. 
With such a heightmap, we could create mazes containing three-dimensional 
structures in a wide variety of shapes, We could create slender walls aligned at 
unpredictable angles. We could create winding staircases and narrow passageways. 

Such a heightmap is theoretically possible. We could use a two-dimensional 
byte array in which each element corresponds to one pixel of the Hoor to store 
the height values. You can probably anticipate some of the problems with this 
approach, though. The most glaring problem is the amount of memory that 
would be required to store such an array, Since it would contain a 1-byte element 
for every point in the fine coordinate sytem, a 16 by 16 maze such as weve been 
using in our demos would require 64 x 16 by 64 x 16, or 1 million, bytes of 
storage. While this isnt entirely out of the question on current generation 
machines, most of which contain at least 4 to 8 megabytes of RAM, it does seem 
rather wasteful. And the size of the array would go up rapidly if the size of the 
maze were increased, A 32 by 32 maze would require 4 megabytes of heightmap 
storage, and a 64 by 64 array would require 16 megabytes, Theres got to be a 
more efhcient way of storing the heightmap data. 

There is. We can tile heightmaps exactly as weve been tiling texture maps. 
The floors of the mazes that we've created in this and the previous chapter have 
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been texture mapped at the level of the fine coordinate system. Yet, by the simple 
expedient of repeating the same texture-map tlles over and over again across the 
Hoor of the maze, we ve reduced the amount of storage necessary for these texture 
maps to a small portion of that required to store a PCX image. We can do the 
same thing with heightmaps: Create a few heightmap tiles and repeat them 
throughout the maze. [The amount of storage required will be minimal, yet well 
be able to pull off heightmapping effects that would be impossible using block- 
aligned heightmaps. 

Alas, there are other problems presented by the use of tiled heightmaps. But 
we ll discuss those problems in the course of developing a demo showing one 
possible way in which tiled heightmaps might be used in a ray-casting engine. 


Creating Height Tiles 


Before we can create a tiled heightmapped version of the dnzw_maze() hanction, 
we need a method of creating height tiles to use it with. Like the texture-map 
tiles that weve been using, each height tile will be a 64 by 64 array of byte values. 
Typing such height data into an array could get tedious, since each array will 
have 4,096 entries. But theres a simpler way to create heighr tiles. We can create 
them exactly as we create texture-map tiles: with a paint program. 

How does one go abour creating height tiles with a paint program? In the 
HEIGHT directory, you'll nd a PCX fle named HIGHMAPS.PCX. Take a look 
ar it using the PCOASHOW’ program from chapter 2 (see Figure 10-10). Like the 
PCX files containing our texture-map tiles, this fle contains 15 heightmap tiles 
stored as 64 by 64 pixel images. The colors in which these tiles have been painted 
arent arbitrary. [he palette number of each color represents the height of the Hoor 
pixel corresponding to that position in the heightmap. For instance, a pixel in a 
heightmap tile drawn in palette color 47 represents a floor pixel that is 47 height 
units above the base Hoor level. Because our ray-casting engine normally sees the 





Figure 10-10 The heightmap tiles in the 
HIGHMAPS.PCX file 
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pixel values in a bitmap as unsigned byte values, it wont even be necessary to 
translate the heightmaps into another format before using them. We'll stmply store 
them as a PCX image and look up individual height values the same way weve 
been looking up individual pixel color values in our texture-map tiles. 

While the relative heights of pixels in the heightmap arent obvious from 
looking at the PCX image, I've included slanted walls and even curved walls in 
this PCX file, to demonstrate the flexibility of tiled heightmapping. 


The Tiled floorheighti] Array 


Well need to incorporate several arrays into the program to tell the ray-casting 
engine how to use these height tiles. The first, and most obvious, of these arrays 
will be the floerberght!/ array. In our block-aligned heightmapping engine, we 
used the floorheight/] array to store the heights of the Hoor squares, In this tiled 
version, well use the floorberght/! array to store the numbers of the heightmap 
tiles to be used for the Hoor squares. A value of 5 in the floonbeight/ | array, for 
instance, means that the heightmap for the corresponding floor square is in 
height tile number 5. Youll note that the floorbeight/} array serves the same 
purpose for heightmap tiles as our flor// and wall// arrays have served for texture- 
map tiles. Here's the floorheight/) array that we'll be using in our demonstration 
program: 


map type floorheight=t 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, O, 0, 0, O, 0}, 
{ 0, 0, 0, 0,-0, 5,.5, 3,-3,.3, 0,.0, 0, 0, 0, GF, 
{ 0, 0, 0, 0,.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
(0. 4, 1: & fh: 05 0. 8) 0,0; O°0, 0,0; 0,03; 
{ 0, 0, 1, 1,0, 0, 0, 0,0, 0, 0, 0, 5,10, 0, OG}, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 6,11, 0, 0}, 
{ 0, 0, 2, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
i 0, 2,2, 0,:0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 2, 0, 0, 0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, 0, OF, 
{ 0,.0,-0, 0, 0, 0;-0, 0,-0,-0, 0, 0, 0:0, 0,03, 
{ 0, 0, 0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, Oy» 0, O, 0, 0, O, 0, 0, 0, 0, 0, 0, 0, 
IF 


The floorbasel) Array 


We'll also create an array called floorbase//, the purpose of which may not be 
readily apparent. Essentially, the fleorbase// array will work exactly like the 
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floorheight// array in the block-aligned heightmapped engine. The numbers in the 
floorbase// array will specify the heights of the individual maze squares. In the last 
program, we calculated the height of the floor trom an assumed base of 0. Now 
well give each floor square an individual base value, as specified in the floor base 
array, The actual heights of the individual Hoor pixels will be calculated as the 
sum of the value for that square in the floerbase// array and the value for that 
pixel in the heightmap tile corresponding to that square. What's the point of 
maintaining a fleerbase/] array? It will allow us to reuse height tiles at various 
height levels throughout the maze. Despite the versatility of the tiled 
heightmapping approach, most of the squares in a maze will still be Hat. But 
some Hat squares will be at low levels within the maze while others may be on top 
of towering balconies. Theres no point in creating several fat height tiles when 
we can simply raise the Hoor base and use the same flat tile at each level. 
Similarly, tiles that represent walls rising from a Hat Hoor can be used in both 
low-lying portions of the maze and elevated portions of the maze, simply by 
raising the Hoor base underneath the tiles. The Hoorbase array that well be using 
in our demo program looks like this: 


map_type floorbase={ 


{G, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, 0, 0, 0, OF, 
fo. 0. 6.0, 0, 0. 0; G, 0, 0; 0,6, BO, 0, 0; Oo}, 
{ G,:0, 0, 0, 0, 0,0, 0, 0, 0, 0, 0, UO, 0, 0, OF, 
4 0, 0, 8, 0,0, 6, 0, 0,.0,0, 0,0, 0,0, 0, 0}, 
(0, 0, 0, 0, 0, D0, 0, O. 0, O, 0, 0, 0, O, DO, OF, 
{i G, 0, 0,0, 0, 0,0, G, 0,0, 0, 0, 0, 0, 0, 0}, 
{ 8,20, 0, 0,-0, 0, 0, G, 0, 0, 0, 0, G, 9, 0, OF, 
{ 0,40,20, 0, 0, 0, 0, 0, 0, OG, 0, 0, 0, 0; 0, OF, 
{ G,40,40,20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
_ 0,40,20, 0, 0, 0, 0, 0, 0, 0, 0, 0, G, 0, 0, OF, 
{ 0,20, 0, 0, D0, 0, 0, 0, 0, O, O, O, O, 0, 0, OF, 
+0, 6, 0, .0,:0,.0,-0, 0,0, 0,9, 0, O,:0, 8, 03, 
‘0, 0, 0, 0, 8, 0,:0, G, 0, 0, 0, 0, 0, 0, 0, Of, 
(0, 0, 0, 0, 0, D0, O, 0, 0, O,-0, 0, 0; 5; DO, OF, 
t G0, 0,.0,-0,. 0,0, 0,0, 0,0, 0, O,.0, 0, OF, 
. & 0, 0, 0,0, 0, 0, 0,0, 0, 0, 0, 0, 6, 0, 0} 


a 
a 


The Tiled flor{t] and wall{} Arrays 


Finally, we'll maintain the flor// and wall!) arrays from earlier versions of our ray- 
casting engine. The flor// array will store indices into a PCX fle filled with 
texture maps, as it did in our earlier programs, but the meaning of the wail// 
array will change. Previously, the wal//! array was used to store pointers to the 
texture-map tiles that were to be mapped onto the corresponding sections of wall. 
Now that we have the ability to create walls tn any shape and oriented at any 
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angle, texture mapping is considerably more difficult, When the walls were 
ruaranteed to be aligned with the maze grids, we could find the appropriate 
column of the texture map by taking the x or y coordinate at which the ray 
struck the wall modulo 64. But how do we find the appropriate column of the 
texture map to map onto a diagonal wall? Or a curved wall? In this chapter we'll 
take the easy way out and drop the texture-mapped walls altogether, drawing the 
walls in solid colors instead, The number in the wafl!/ array for a given square 
will indicate what color the wall is to be drawn in. This allows us to perform a 
kind of rough-and-ready shading on straight and diagonal walls, but ir doesnt 
work very well on curved walls, as youll see in a moment. After we demonstrate 
the tiled heightmapping engine, I'll suggest some alternate methods that might 
be used for texture mapping heightmapped walls, 
Now let's develop a tiled heightmapping version of the draw_maze() function. 


A Tiled Heightmapping Engine 

Because height changes in a tiled heightmap are aligned at the level of individual 
Hoor pixels rather than at the level of the maze grid, we can no longer cast for 
walls by casting rays against x and y grid lines. The best way to cast for height 
changes would, in fact, be to test every pixel along the path of the ray to see if a 
height change has occurred, perhaps using a variation on Bresenhams algorithm 
to determine the path that the ray takes. Such a program wouldnt be terribly 
difficult to wrire, but it would be excruciatingly slow in execution. 

An alternative method would be to cast for height changes at the same time as 
we cast for the color of the Hoor pixels. This would not only be relatively fast, but 
it would be easy to write. We could drop the wallcasting code altogether and 
write a tight Hoorcasting loop instead. The disadvantage of this method is that it 
can miss changes in floor height altogether, especially when the ray is more than a 
few maze squares away from the viewer and the angle of the ray becomes shallow. 
For the most part, this won't matter. If a wall or raised section of Hoor is thick 
enough, well pick it up a few Hoor pixels past the actual height change. The fact 
that the ray penetrates a slight distance into the wall wont be obvious on the 
SCIeen, There's a second drawback to this method FB well, but we ll talk about 
that later in the chapter. 

We'll use the second method in this chapter, not because it's perfect but 
because its relatively fast. A few years from now, about the time thar Intel 
introduces the Octium microprocessor, the average PC should be fast enough to 
make the first method feasible, 

Here's the prototype for this latest version of the draw_maze() function: 


void draw_maze(map_type wall,map_type floor, 
map type floorheight,map_type floorbase, 
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char far “screen,int xview,int yview, 
float viewing angle,int viewer_height, 
char far *textmaps,char far “highmaps) 


This version passes the address of the buffer containing the heightmaps in the 
pointer Aighmaps and a pointer to the array of floorbase heights in floorbase, We'll 
place this prototype in the fle TILEDEMO.H in the HEIGHT directory. The 
function will go in the TILEDEMO.CPP fle in the same directory. 

This version of the draw_maze() function, like all of the other ray-casting 
versions, is structured as a large for() loop that iterates through all of the columns 
in the viewport. At the beginning of the loop, we calculate the viewing angle for 
the current column exactly as in earlier versions. Then we calculate the viewer's 
height much as we did in the previous function, by determining which maze 
square the viewer is standing on and retrieving the corresponding value from the 


Hoorbeighe! |: 


int xmaze = xview/64; 
int ymaze = yview/s/64; 
int floortile=floorheightCxmazellymazed; 


This time, however, we use a somewhat different method of retrieving the 
height of the pixel chat the viewer is standing on, employing the same method 
that we've used in the past for finding the color of a floor pixel in a texture-map 
tile. Remember that the heightmaps, like the texture maps, are G4 by 64 tiles in a 
320 by 200 PCX image, arranged in three rows of five maps each. We can find 
the number of the row by dividing the tile number (in floortile) by 5, get the size 
of a row by multiplying 320 (the screen width) by 64 (IMAGE HEIGHT), and 
then multiply the tile number by the row size. To get the position of the tile, we 
take the tile number modulo 5, then derive the row offset by multiplying this 
number by 64 (IMAGE WIDTH). Finally, we obtain the actual position within 
the tile by taking yerew modulo 64 (IMAGE HEIGHT), multiplying it by 320 
(the screen width), and adding in xvew modulo 64 (IMAGE_WIDTH). Whew! 


Here's the resulting instruction: 


int currentheight=highmapsl(floortile/5)}*320* IMAGE HEIGHT 
#(floortilesS)* IMAGE WIDTH 
+(yview%IMAGE HEIGHT) *320 
+(xviewZIMAGE WIDTH}]; 


We'll cast for the floor pixels exactly as we did in the ray-casting engine we 
developed in the last chapter. However, we'll include code in the Hoorcasting loop 
to abort the casting when the edge of the map is reached: 
if (Cxmaze<0) | | (xmaze>=GRIDWIDTH) 


|| Cymaze<0) | | (ymaze>=GRIDWIDTH?)) 
break; 
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As in the first program in this chapter, we can no longer depend on there being a 
wall to stop us at the edge of the maze. 

Well determine the height of floor pixels much as we determine the color of 
Hoor pixels. First well calculate a value ¢ that represents the column in the height 
tile corresponding to the current Hoor pixel: 


int t = Clintdy & Ox3f? * 320 + (Cint)x & Ox3t); 

Then we'll store the number of the height tile for the current floor pixel in the 
variable file: 

int tile=floorheightl[xmazel]lymazel; 

Finally, well calculate the offset of the relevant byte of height data within the 
PCX image containing the heightmaps: 

unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tilez5) 


*IMAGE_WIDTH+t; 


To get the actual height of the Hoor pixel, we need to add the height value 
from the heightmap file and the fleerbase/] array value for the maze square 
containing the Hoor pixel: 
int newheight=highmapsltileptrid+floorbasel xmazellymaze; 

If the Hoor level has gone down, the wall is facing away from us, so no wall 
needs to be drawn. All we need to do is reset the Hoor height and keep casting: 
if (newheight < currentheight) currentheight=newheight; 

The other possibilities, of course, are that the floor level has gone up or that it 


has not changed at all. In the latter case, we do nothing and continue casting. If 
the Hoor has Porne Up, then We prepare for drawing the wall: 


else f 

if (newheight > currentheight) f 

We still need to reset the floor height: 
currenthei ght=newheight ; 

We can use the similar triangles method to find the screen row corresponding 
to the top of the wall: 


ratio = (float) VIEWER_DISTANCE/real_distance; 
int a = ratio*(viewer_height-currentheight); 
int newrow = VIEWPORT_CENTER + a; 


We can then calculate the offset in video memory to begin drawing the wall at 
and draw pixels trom there TO the Screen Fow corresponding co the bottom at the 


wall: 
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offset=row*320+column; 

for €int i=row; i>newrow; --7i) f{ 
screenLoffsetJ=wallLxmazellymazel; 
of fset==320; 

} 


Note that the color for the wall is taken from the wl! array entry corresponding 
to the current maze square. 

Once the wall is drawn, we can reset the rew variable to the screen row directly 
above the top of the wall: 

row=newrow; 

} 

Whether or not there was a change in floor height, we must draw the 
floor pixel at the current position. However, we must first check to see that 
the Hoor pixel is visible — that is, that it is below the viewers eye level, which ts 
presumed to be at VIEWPORT _CENTER: 
if (row > VIEWPORT_CENTER) { 


The rest of the Hoorcasting — which ts the rest of this function — proceeds 
exactly as it did in the ray-casting engine in the last chapter. 


The Tiled Heightmapped draw_maze() Function 
The complete text of the tiled heightmapped version of the araw_maze function 


appears in Listing 10-3. 






ae Listing 10-3 [he tiled heightmapped draw_mazel) 
Function 


fi 

‘f/f TILECAST.CPP 

‘/ Draws a tiled heightmapped three-dimensional maze 
// Written by Christopher Lampton 

// for Gardens of Imagination (Waite Group Press) 


Ainclude <stdio.h> 
Hinclude <math.h> 
Finclude “tilecast.h” 
finclude "pex.h" 


const WALL _HETGHT=64; ff Height of wall in pixels 
const VIEWER_DISTANCE=128; ‘i Viewer distance from screen 
const VIEWPORT_LEFT=0; ‘/ Dimensions of viewport 
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const VIEWPORT_RIGHT=319; 

const VIEWPORT _TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT_BOT-VIEWPORT_TOP; 
const VIEWPORT_CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/?2; 
const Z00M=2; 

const GRIDWIDTH=16; 

const WALLCOLOR=18; 


void draw_maze(map_type wall,map type floor, 
map type hightile,map_type floorbase, 
char far “screen,int xview,int yvieu, 
float viewing_angle,int viewer_height, 
char far *textmaps,char far *highmaps) 


int y_unit,x_unit; // Variables for amount of change 
‘f/f in = and y 

int distance,real_distance,old_distance,xd,yd,5%,sy; 

unsigned int offset; 


‘/ Loop through all columns of pixels in viewport: 
for Cint column=VIEWPORT_ LEFT; column<VIEWPORT_RIGHT; column++) ¢ 


ff Calculate horizontal angle of ray relative to 

// center ray: 

float column_angle=atan((float)(Ceolumn-160)/700M) 
/ VIEWER_DISTANCE); 


‘/ Fudge column angle: 
1f Ccolumn_angle==0.0) column_angle=0.0001; 


‘/ Calculate angle of ray relative to maze coordinates 
float radians=viewing_anglet+column_angle; 


// Which square is the viewer standing on? 
int xmaze = xview/é64; 
int ymaze = yview/64; 


// Get pointer to floor height map: 
int floortile=hightilelxmazellymazel]; 


/f How high 71s the floor under the viewer? 

int currentheight=highmapsl(floortile/5)*3520*IMAGE_HEIGHT 
+(floortile<5)* IMAGE WIDTH 
+(yviewXIMAGE HEIGHT)*320 
+(xviews IMAGE WIDTH]; 


ff First screen row to draw: 
int row=VIEWPORT_BOT; 


// Cast a ray across the floor: 
for tes7-% 


// Get ratio of viewer's height to pixel height: 
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float screen_height=row-VIEWPORT_CENTER; 
if (scereen_height==0.0) screen_height=.U0001; 
float ratio=(float)(viewer_height-currentheight?)/screen_height; 


ff Get distance to pixel: 
real_distance=ratio*VIEWER_DISTANCE; 

if (real_distance>old_distancet5) distance+=5; 
distance=real_distance/cos(column_angle); 


‘f Rotate distance to ray angle: 
int x = - distance * (sin€radians)); 
int y = distance * (cos(radians)); 


if Translate relative to viewer coordinates: 
K#=KVIEW; 
yt=yview; 


// Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 


‘f If we've reached the edge of the map, quit: 
if ((xmaze<0) | |(xmaze>=GRIDWIDTH) 
|| Cymaze<0) | | Cymaze>=GRIDWIDTH)) 
break; 


ff Find relevant column of texture and height maps: 
int t = (Cintiy & Ox3t) * S20 + (Cintix & Ox3tf): 


ff Which height tile are we using? 
int tile=hightileCxmazeJlymazel; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tilexz5) 
*IMAGE_WIDTH+t; 


// Get height of pixel: 
int newheight=highmaps(tileptrJ+floorbaselxmazellymazed; 


ff Has the floor level gone down? 
if (newheight < currentheight) currentheight=newheight; 


else f 


‘f/f Has the floor Level gone up? 
if (newheight > currentheight) f{ 


‘/ If so, set new floor height: 
currentheight=newheight; 


‘f If so, calculate new screen position: 
ratio = (float) VIEWER_DISTANCE/real_distance; 


CONES On Mext page 


_— eg 
a | 


r = = a 
| 
| — 


Sa 


Fl ee 


GARDENS OF IMAGINATION 
cone PhO rer inied page 


int a = ratio*(viewer_height-currentheight); 
Int newrow = VIEWPORT_CENTER + a; 


// Draw wall segment: 

of fset=row*3204+column; 

for (int j=row; i>newrow; -—-i) f 
screenLoffset J=wal \Cxmazellymazel; 
offset-=320; 

} 


// Set screen row to new position: 
rOowW-NnewrOW 


} 


// If viewer is Looking down on floor, draw floor pixel: 
if (row > VIEWPORT_CENTER) ¢{ 


// Which graphics tile are we using? 
tile=floorExmazellymaze]; 


ff Find offset of tile and column in bitmap: 
tileptr=(tile/5)*320* IMAGE _HEIGHT+(tilex<5)*IMAGE WIDTH+t; 


ff Calculate video offset of floor pixel: 
of fset=row*320+column; 


// Draw pixel: 
screenLoftfsetJ=textmapsCtileptrd; 


if Advance to next screen Line: 
row-—; 


The TILEDEMO.CPP Program 


To demonstrate this new ray-casting function, we'll call it from a short program 
called TILEDEMO.CPP. The complete text of this program is in Listing 10-4. 





Listing 10-4 The TILEDEMO.CPP program 


// TILEDEMO.CPP 
if 
‘f Calls ray-casting function to draw view of 
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‘ff tiled height=mapped maze. 

ii 

if Written by Christopher Lampton for 

if Gardens of Imagination (Waite Group Press) 


finclude 
finclude 
Ainclude 
Finclude 
finclude 
finclude 
finclude 


<stdio.h> 
<dos..h> 
<conia.h> 
<stdlib.h> 
<math.h> 
“screen.h" 
"ocx .h" 


Finclude “tilecast.h” 
const NUM_IMAGES=15; 
pex_struct textmaps,highmaps; 


map type waLll= 


6,20, 05°02 °0,-0,.0, 8.0, 0,-0.6, &,:6, 0,0), 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0, 0, t, 0, 0, 0, 0,0, 0,.0, 0, OF, 
£ 0, GO, 0,0, :0,:0;.5, G,.0, 6,0; 6, 0,-0, 0; GF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{_0,26, 0,-0.0; 0,0) 0-0, 0 0, 0, @, 8, &,.-0F, 
{ 0,28,28, 0, 0, 0, 0, 0, 0, 0, 0, 6, 0, 0, 0, dO}, 
{ 0,28,28,28, 0, 0, 0, G,: 0, 0, 0, 0,18,18, 0, O}, 
{ 0,22,22,2¢, 0, 0, 0, 0, 0, 0, 0, 0,18,18, 0, OF, 
CO, 3,17, 0, 0,20, 0, 0, 0 0, 0, G, 0, 0, OF, 
£O,17,17; 0, 0, 0,0, O,.0; 0, 0,0, 0,0, 0, -OF, 
10-17, 0,0) 0, 02-0, 8a, 8,..0,-8. G.- 0; 0-8, 
6,30, 6,.0,-0,.8,-40; ¢,4):6..0,. 0.68.8) @.-8, 
{.0,-G, 0, 0, 0,0, 0, 0, 0, 0, 0, 6, 0, 0, G, OF, 
CO: G,:05 0; 05-0, 06:0; 6.6.0: 0.0, G,.-, 
(0, 0, G0, 0, 0, 0, 0,0, O,_.0,.0,.0,.0, 0.0 

t; 

map type flor=t 

C0, G, 0,0, 0, 0,0, G, 0,6, 0, 0, 0, 0, 0, 07, 
{ 0, 0, 0, 0, O, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0,0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
Oe Bie ee See ae ee ey Oy EO, 
iO, 0; 0,0, 0, 8.0, 0.28, 0, 0, 8, 0,0, 6; OF, 
C0, 1, G;-0, 0, 0, 0, 0,:0, 0,0, 0, 0, 0, O,-0}, 
CO Te, 1,00, 00,. 0,0, 8-0, 6,.0,-0,.0,°6, 0,0), 
(0, 12,12, 1, U, 0, 0, 0.0, 0, 0,-0, 5,10; &,. 0}, 
{ 0,12,12,12, 0, 0,0, 0, 0, 0, 0, 0, 6,11, 0, OF, 
{0,12,12,-2, 0, 0, 0, 0, 0,0, 0, 0, 0,0, 0, 0, 
iu le, 2, 0, 0, 0,0, &€,-0, 0,.0, 0, 0, 2 0, OF, 
0, 2, G,. 0, 0,0, 9, 0,0, G,. 0, 6, 0,0, 0,0), 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0,0, 0, 0,0, 0,0, 0, 0,0, 0,0}, 
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// Load texture map images: 
if CloadPCX("imagese.pex" gtextmaps)) exit(1); 
if (loadPCX("highmaps.pex",&highmaps)) exit(1); 


// Point variable at video memory: 
char far *screen=(char far *)MK_FPCOxall00,0); 


// Save previous video mode: 
int oldmode="*Cint *)MK_FP(Ox40,0%49) > 


‘i Set mode 13h: 
setmode(Ox13); 


// Set the palette: 
setpalette(textmaps.palette); 


/* Clear the screen: 
cls(sereen); 


‘/ Draw a raycast view of the maze: 

draw _maze(wall,flor,floorheight,floorbase,screen, 
aView,¥View,Viewing_angle,viewer_height, 
textmaps.image,highmaps. image); 


// Wait for user to hit a key: 
while ('kbhitt)); 


‘/ Release memory 
delete textmaps. image; 


ff Reset video mode and exit: 
setmode(oldmode): 


To run the program, go to the HEIGHT directory and type TILEDEMO. 
Youll see the circular formation in Figure 10-11, Type TILEDEMO 3.14 and 
you ll see the wedge-shaped structure in Figure 10-12. And if you type 
TILEDEMO 1.57, youll see the series of circular posts in Figure 10-13. The 
rexture-map tiles for the Hoor are taken from the hles IMAGES2.PC% in the 
HEIGHT directory. They were created specifically to go with the height tiles in 
HIGHMAPS.PCX. 

Type TILEDEMO 3.14 250 to get a look at the wedge-shaped structure from 
a considerable height, and you'll see another Haw in this method of casting for 
height changes (see Figure 10-14), The front of the wedge-shaped structure, 
which should be partially obscured by the bottom of the viewport, will move 
back until its flush with the bottom, Why does it do this? Because we didnt cast 
for height changes between the viewer and the bottom of the viewport. The 
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Figure 10-11 A circular formation made Figure 10-12 4 wedge-shaped structure 
from Neight tiles 





Figure 10-13 A row of circular posts Figure 10-14 Height changes between 
the viewer and the bottom of the 
viewport are missed by TILEDEMO 


program assumes that no such changes occur. We didnt cast for such height 
changes because that would slow down the code considerably, and would make 
the function considerably more complicated to write. Similarly, if any height 
changes are obscured by a closer wall, they will be missed by the Hoorcasting 
routine. One solution to this problem might be to perform spot checks for height 
changes below the bottom of the viewport and behind walls, but slender walls (or 
the corners of walls) might still be missed. 


Hybrid Heightmapping Methods 

Which, if any, of the above methods are programs like Doom using? Probably 
neither. It's clear from the visual effects that it achieves that Doom is not using 
block-aligned heightmapping, a method that can provide some quick and dirty 
heightmapping tricks but is too limited to depict walls thar arent aligned at 90) 
degrees to the maze grid or that are less than a maze square in thickness. And tt 
probably does not use tiled heightmaps, which have Haws that only the CPU- 


intensive solutions suggested in the last paragraph would solve, 


396 
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There are, however, heightmapping algorithms that combine the elements of 
both techniques. Theres not enough space in this book to cover them, burt you 
might want to explore them on your own. Basically, these hybrid methods would 
specify height changes on a block-aligned basis, so that it would only be 
necessary to check for height changes at block boundaries. But the height 
changes themselves would not necessarily have to take place at those boundaries. 
While only one height change might be allowed per block, that height change 
could slash across the middle of the block at an arbitrary angle rather than along 
the edges of the block. Each entry in the wafls// array could contain a Hag 
indicating that a height change takes place in that block, If one does, the entry 
would also contain the slope at which that change is oriented relative to the maze 
erid and the coordinates at which it crosses the edges of the block (or a pointer to 
a separate structure that contains this information). A more ambitious system 
would allow each block to contain a pointer to a linked list that could contain an 
unlimited number of height changes, all of which occur in thar block. Such a 
system could simulate a tiled heightmap system, but would run much faster. 

Is this what the Doom programmers have done? | have no idea. However, it 
should be possible to duplicate most if not all of the floor and wall effects in 
Doom by using such a system, 


Animated Heightmaps 


Once youve developed a heightmapping system, theres no reason that you 
should stop there. There are a number of special effects that can be achieved by 
animating the heightmaps. For instance, you could raise and lower heightmaps 
dynamically to create an elevator, In a block-aligned heightmap, this is only a 
matter of changing the number in a single position in the floorberght/ | array, 
assuming that the elevator occupies a single maze square, (For larger elevators, 
just change the numbers in several different positions.) By increasing the Hoor 
height on every frame, a section of floor will appear to detach itself and rise 
toward the ceiling atop a thick column. If the player character is standing on that 
block, he or she will automatically be lifted along with it. (This will be handled 
automatically by the ray-casting code tn this chapter, which always checks the 
height of the Hoor pixels beneath the viewer's feet before casting the image.) 
Reducing the number in the height array corresponding to a maze square will 
cause the Hoor of that square to go down, even below the height of surrounding 
squares if those squares are higher than the base level. 

Changing the floor level more rapidly than this creates a trapdoor over a 
hidden pit. When the unsuspecting player character steps on that square, lower it 
by a few dozen height levels — and the viewer will seem to plunge in after it. You 
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can then lower his or her hit points to represent damage from the fall, if that 
strikes you as appropriate. And you can use texture mapping to write messages on 
the walls of the pit that the player cannot see until he or she takes the plunge, 
perhaps representing important clues toward completing the game. 

If youre using a tiled heightmapping system, raising or lowering the Hoor need 
not be any more complicated than with a block-aligned system. To raise a section 
of Hoor, you can change the level in the floorbase// array rather than altering one 
of the height tiles. If you want your clevator to have nonaligned walls, you can 
maintain a sequence of height tiles that represent the floors height at various 
stages in the process. And if this requires too many height tiles for the available 
memory in the computer, you can actually modify the height tile itself 
dynamically. 

Once you get into dynamically modifying height tiles, even more bizarre 
effects became possible. For instance, the oor can morph from one shape to 
another, going from Hat to pyramidal, or sinking to form a bowl-like pit with 
sloping edges. Use your imagination. With heightmaps, the sky's the limit! 
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ight is the soul of ray casting. By following beams of light from 
the viewers eye through an array representing a maze, we can 
produce remarkably realistic visual effects. So far, however, we've 
only modeled the way in which light moves through the maze. 
+ We've made no attempt to capture the way in which light 





intensities vary across the surfaces in the maze. 

This may not sound terribly important, but by giving our ray-casting engine 
the ability to dynamically alter the brightness of surfaces according to the ways in 
which rays of light strike them — a process known as fightiourcing — we can 
ereatly enhance the realism of the images thar it produces. Our murky mazes will 
really /oo# murky, with shadows filling distant hallways and corners of large 
rooms, Distant surfaces can be made darker than nearer ones, a visual cue that 
will make our mazes look even more three-dimensional than they already do. 
Pools of light can be placed around lamps and torches. Flashes of light can 
accompany the explosion of a fireball. And lightsourcing can also be used to 
create visual effects that at first glance seem to have little to do with light, such as 
filling the maze with fog or even water. Best of all, lightsourcing is fairly easy to 
add to a ray-casting engine and the cost in added CPU cycles is small. 
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Casting Some Light on Light 


Light is a form of radiation. That doesn't mean that you should don a radiation 
suit the next time you head to the beach (though some SPF-30 sunblock might 
not hurt). It simply means that light radiates ourward in all directions from the 
source thats producing it, as in Figure 11-1. We can imagine that the wavefront 
of photons leaving a light source at any given instant in time is an expanding 
sphere, growing larger at the speed of light (see Figure 11-2), If there’s nothing 
standing in its way, this sphere of light can expand for a very long time. When 
astronomers turn their telescopes on distant quasars, theyre catching a tiny 
portion of an expanding light sphere that left its source more than ten billion 
years ago, [hats a long time to spend traveling in the icy vacuum of space. 

If these particles of light happen to be heading in your direction and you 
happen to be looking toward the light source when they reach you, some of them 
will strike your eyes. If enough of them strike at one time, they will activate 
photosensitive receptors and trigger a visual signal in your brain. This visual 


signal tells you that you re looking toward <i light SOLUTCE. You will, quite literally, 
SCC the light. 

How bright the light appears depends mostly on three factors: how much light 
the light source is producing, how much of the light gets absorbed or knocked 
aside on its way to your eyes, and how far away you are from the source. We'll 
talk about all of these factors in the course of this chapter, but for now we'll 
concentrate on the third: distance. 





Figure 11-1 Light soréads out in all Figure 11-2 The photons leaving a light 

directions from its source source at any given instant form an 
expanding sphere of light around the 
source 
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As the sphere of light expands, the particles making up the sphere grow farther 
apart. When the sphere reaches your eye, fewer particles hit your eye and the 
visual signal in your brain grows weaker, making the light seem dimmer. This is 
why stars, the brightest light sources that you can see with your naked eyes, look 
a lot dimmer than the feeble streetlamps that routinely drown out their light. 

Most of the light that reaches our eyes doesn't come directly from a light 
source. It is reflected off the surfaces of other objects. The amount of light 
reaching these surtaces also depends on how close they are to the light source. 
The closer a surface is to a light source, the more light it reflects and the brighter 
it appears to be. The farther away it is from a light source, the darker the surtace 
appears. This effect won't be obvious when you're outside on a sunny day, since 
most of the objects that youll see are roughly equidistant from their primary 
light source: the sun. But it's immediately apparent in a room that is illuminated 
by a single light source, such as a lamp. Light will seem to pool in the vicinity of 
the lamp, bur will fall off into dark shadows in distant corners. 

What does this have to do with maze games? A lot of games take place in dark, 
dank dungeons, which are presumably illuminated only by a torch carried in the 
hand of the player character. Presenting such mazes in full illumination, as we 
have done up until now, isnt really realistic. In the real world, the player would 
find that surfaces in his or her immediate vicinity are more brightly illuminated 
than surfaces in the distance. In a large room or a long corridor, distant walls may 
be so dimly lit as to not be visible at all. To the player, the light of the torch 
would seem to form a circular pool of brightness that dims rapidly into the 
distance (see Figure 11-3). 
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Figure 11-3 The liaht of the torch forms 
a circular pool around the player, 
dimming into the distance 
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We can simulate this effect in our ray-casting engine by making distant walls 
darker and by making the pixels in both the Hoor and ceiling grow dimmer as 
they recede from the viewer. This addition wont even take a lot of extra code. It 
will, however, require at least some understanding of how the intensity of light 
decreases with distance. 


The Inverse Square Law 

A moment ago, | compared the wavefront of photons leaving a light source to an 
expanding sphere with the light source at its center. The density of photons on 
the “surface” of this sphere determines how bright the light source will appear to 
an observer. Because the photons spread out as the sphere expands, the light 
source appears dimmer with distance. A little thought tells us that there's a simple 
rule governing the rate at which the light dims, 

Figure 11-4a depicts a light sphere with a radius of r. If you were standing at a 
distance of r from the light source producing this sphere, your eyes would 
intercept photons from the surface of this sphere. The small square on the surtace 
of the sphere represents the section of the sphere that strikes, and enters, your 
eyes. (I've exaggerated the size of this square to make it easier to see.) Figure 
11-4b represents a light sphere with a radius of 2 x r, ewice that of the sphere in 
Figure 1 1-4a, The tiny square has expanded to a square with twice the height and 
twice the width (and therefore four times the area) of the square in Figure 1 1-4a. 
However, if you were standing at a distance of 2 x r from the light source, your 
eyes — which havent grown any larger — would only intercept the photons in 





Figure 11-4a An expanding liaht sphere. Figure 11-4b The same sphere at twice 
The square patch is the area intercepted the distance, The square patch has 
by your eyes expanded to four times its previous area 








CHAPTER ELEVEN Lightsourcing 


the smaller dotted square inside of the large square. This square contains only 
one-fourth as many photons as the original, since the photons from the original 
square have now spread out to form the larger square. Thus the light source 
would appear only one-fourth as bright. 

The same thing would happen if you were standing 3 x r from the light 
source, except that the small square would only be 1/9th as large as the original 
square and thus the light would seem 9 times dimmer. At a distance of 4 x 1, the 
small square would be only 1/16 as large as the original square and the light 
would seem 16 times dimmer. At 5 x r, the small square would be 1/25th as large 
as the original square and the light 25 times dimmer. And so forth. 

Astute readers will notice that the light grows dimmer as the square of the 
distance increases. This is known as the rnverse square daw and represents the way 
that the intensity of a//forms of radiation falls off with distance, not just light. As 
a peneral rule, we can say thar if a light has an apparent brightness of B at a 
distance of D, it will have an apparent brightness of 1/(A°) at a distance of X x D. 

There's a catch to this rule, however. It only applies to a light source that has 
no size — that is, it assumes that the light is emanating from a single point in 
space. In the real world, light sources tend to be larger than this, which causes the 
light co fall off more slowly with distance. 5o we cant use the inverse square law 
as a realistic model for the way light intensity changes. What will we do? 


The Lightsourcing Formula 

My own solution was to pull a copy of Computer Graphics by Donald Hearn and 

M. Pauline Baker (Prentice Hall, 1986) off my bookshelf and look to see if it 

contained any formulas relating to light intensity, What I found was this: 

ro te 
d+d. 





(N-L) 


where I is the intensity of the light on the surface, k, is the reflectivity of the surface, 
I, is the intensity of the light source, d is the distance from the light source to the 
surface, d, is a fudge factor that avoids divide-by-O errors when the light source 
and the surface are very close, N is a vector representing the surface normal of the 
surface, and L is a vector representing the direction of the ray of light striking the 
surface, 

Got that? Good. Now forget it, because were not going to be using that 
formula, We dont need the business with the surface normal and the light ray 
vector because the light source is always originating at the viewer (who will be 
carrying the torch) and the light always reflects straight back from the surface to 





GARDENS OF IMAGINATION 


the viewer. Thus the two factors cancel each other out. We don't need the fudge 
factor because we already have a fudge factor preventing the distance from getting 
too small, And we dont need the reflectivity factor because we're going to assume 
thar all surfaces in the maze are equally reflective. 

In practice, | find that this simpler formula produces perfectly reasonable 
results: 


intensity_ratio = intensity_of_source / distance_from_source * MULTIPLIER 


where intensity_ratio is a floating point number in the range 0 to 1 that represents 
how bright the surface appears relative to how it would appear in full light (with 
| representing full intensity and 0 representing black), and MULTIPLIER is a 
constant that prevents the light intensity from falling off too rapidly with 
distance, so that even nearby walls would be invisible. I recommend a value of 3 
for this constant, but feel free to try other values. 

Theres nothing sacred about this formula. | use it because it works. But if you 
find one that works better, you should use it in preference ta this one (and I 
wouldnt mind if you let me use it too). There’s no point in spending too much 
time worrying about whether our lightsourcing equations produce accurate 
results, though. What matters is that those results look realistic to the viewer, 
who probably wont be examining the video display with a light meter. Thus we 
can get away with a lot of simplification. 

Betore we can Use this formula, We need to know what numbers To assign to the 
variables. Obviously, the distance_ from_source factor in this formula will be the 
distance of the light source in pixel units from the coordinates xview,yuiew at 
which the viewer is standing, since our engine already calculaves that distance and 
makes ir readily available in the variable distance. But how are we going to measure 
the intensity of the light source? Surprisingly, we can measure it using any method 
we want to, as long as we use that method consistently throughout the program. 

The method that we'll be using in this chapter will represent the intensity of 
light sources with a number in the range Q to 32, with 32 representing the 
maximum possible intensity and 0 representing complete darkness. We Il measure 
the brightness of surfaces the same way, with a brightness of 32 indicating that 
the pixels appear exactly as they would if no lightsourcing were applied (that is, as 
they ve appeared in the last two chapters) and 0 indicating that all pixels have the 
same color: black. Values berween 0 and 32 will indicate degrees of brightness. 
For instance, an intensity value of 16 will indicate that the pixels on the surface 
appear half as bright as they do at full intensity. 

To perform lightsourcing on a pixel, we must calculate the distance to the 
pixel, apply the lightsourcing formula to get the value of intensity_ratio, and 
multiply satensity_ratio by the brightness of the pixel to determine the actual 
color that we are to place on the screen. 
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But how do we know what the brightness of the pixel is? When we copy a 
pixel from the texture-map buffer to the screen, all we know ts the palette 
number of the pixel. We dont even know what color it is (which can vary from 
palette to palette) much less how bright it is. 

Youll recall that the VGA color registers contain three numbers in the range 0 
to 63 for every color in the palette. These numbers represent the red, green, and 
blue intensities of the color, For instance, a medium gray shade might be 
represented by the numbers 32,32,32, meaning that red, green, and blue are all at 
about half their maximum intensities. A bright red color might be represented by 
the numbers 63,0,0, indicating that red is at full intensity while green and blue 
are al MINIMUM Intensity. 

To change the brightness of the red, green, or blue component of a color, we 
must increase or decrease the number representing that component. If we increase 
the number representing the Breen component ot al color, for instance, Wwe make 
that component brighter. If we decrease the number, we make that component 
darker. However, if we raise and lower these numbers indiscriminately, we can 
actually change the color. Increasing the green component of a color may make 
the Preetl component brighter, but it also makes the color itself SCC More Breen. 

To change the brightness of a color without changing its hue, we must be 
careful to increase or decrease all three color components together. Furthermore, 
we must take care to preserve the relationship between these components, because 
it 1s that relationship that establishes the hue. For instance, all colors in which the 
three color COMpPONnents are equal aie shades of BAY. We Cel fl Increase OF decrease 
the intensity of the color by increasing or decreasing the color components. Bur if 
we want the color to stay gray, we must be sure the three components are always 
equal, 
This isn't hard to do. We just have to multiply all three components by the 
same lightsourcing factor. The factor that well be using is the stenstty_ratio 
component from the formula above. You'll recall that this number is a fraction in 
the range 0 to 1, To find the lightsourced RGB components of a pixel, we need 
merely multiply this fraction by the non-lightsourced RGB values for the pixel. 
Suppose, for instance, that we wish to place a pixel on the display that has non- 
lightsourced RGB components of 48,32,16, And suppose that, after solving the 
lightsourcing equation for the distance berween the viewer and the pixel, we 
determine that ffensity_ratio has a value of 0.5 (meaning that the pixel should 
appear half as bright as in full light). To determine the lightsourced value of the 
pixel, we simply multiply each of the RGB components by 0.5, producing 
lightsourced RGB values of 24,16,8. What could be easier? 

A lot of things, actually, While all of this sounds fairly simple in theory, the 
way that colors are handled by the WGA adapter makes lightsourcing a great deal 
more difficult than it should be. For one thing, its rare that multiplying RGB 
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values by sntensity_ratio will produce integral values. More likely, it will produce 
three fractional values, such as 17.9,50.231,39.8. This is a minor problem, since 
its fairly easy to round such numbers to the nearest integer, and the difference 
will generally be unnoticeable to the viewer. Far more troublesome is the fact 
that, despite being able to produce 64 x 64 x 64 (or 262,144) different colors, the 
VGA adapter in mode 13h only allows us to place 256 of them on the sereen at 
one time. So just knowing what color needs to be placed on the display to 
represent the lightsourced value of a pixel isn't enough. We must then find out if 
that color is present in the 256-color screen palette. [f it isn't (and it usually won't 
be), we need to find the closest approximation of that color and use it instead. 

This can be quite a time-consuming process. Performing these operations 
while casting rays through the maze could slow our ray-casting engine to a crawl. 
Fortunately, theres no need to perform these calculations on the fy. We can 
perform them in advance, save the results in a couple of arrays, and pass those 
arrays to the ray-casting engine, which can simply look up relevant values as it 
requires them. 

The first of these arrays will be a pwo-dimensional array — that is, an array of 
arrays — in which there are 32 entries for every color in the 256-color palette. 
This may sound like rather a large array, burt it will only take up 8 kilobytes of 
our precious computer memory, The advantages we gain from this array will be 
well worth the sacrifice. The 32 entries for each palette color will contain the 
palette numbers ot other palette colors that COM closest to approximating the 
way that that color would look at each of the 32 light levels. (Actually, there are 
33 light levels, counting 0, so this array will really contain 33 entries for each of 
the 256 palette colors.) 

This is a potentially confusing concept, 50 ['ll pause here for a moment to 
explain it in more detail. Suppose that palette color 10 is a shade of gray with 
RGB values of 32,32,32. Since we're using an intensity scale that runs from 0 to 
32, it’s not difficult to see what the ideal list of lightsourced colors for this color 
would look like. At an intensity level of 0, it would have RGB values of 0,0,0. 
(Actually, every color has RGB values of 0,0,0 — pure black at intensity 0,0,0.) 
At intensity 1, it would have RGB values of 1,1,1. At intensity 2, it would have 
RGB values of 2,2,2. And so on, all the way up to intensity 32, where it would 
have RGB values of 32,32,32. 

Enctry 10 in the lightsourcing array would consist of the numbers of the 32 
colors that represent lightsourced versions of color 10. Ideally, the first entry in 
the list (corresponding to a light intensity of 0) would be the number of the color 
with RGB values of 0,0,0. Since that color is pure black, it almost certainly wall 
be in the list, since almost every palette contains black. If black is color 0 in the 
palette, the first entry in the array for color 10 will be 0. If the color with RGB 
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values of 1,1,1 is also in the palette, its number will be entry 2 in the list. If it 
isnt, then entry 2 will contain the number of the color that most closely 
approximates this color. For instance, if the color with RGB values 2,1,1 ts in 
the palette, its number may appear in entry 2 instead. Its not quite the right 
color, but its close enough. Entry 3 will contain the color that comes closest 
to having RGB values of 2,2,2, entry 4 will contain the color that comes 
closest to having RGB values of 3,3,3, and so forth. The last entry will represent 
the palette color that best represents the color at intensity 32. Since this is full 
brightness, the last entry will always point to the color itself. For color 10, the last 
entry will be 10. 

Once weve created these tables, finding the lightsourced color of a pixel will 
be a simple matter of calculating an intensity number in the range 0 to 32 that 
represents the intensity of the light falling on that surface and looking up the 
equivalent entry in the table of light source values for that color. We can calculate 
the intensity number by solving the lightsourcing formula for the value of 
intensity_ratio, then multiplying intensity_ratie by 32. All clear? 

For example, if the lightsourcing tables are contained in the nwo-dimensional 
array behtsource!///, where the number in the first pair of brackets represents the 
palette number of the color and the number In the second pair at brackets 
represents the light intensity, we can find the lightsourced value of a pixel like 
this: 
float intensity_ratio = intensity_of_source / distance * MULTIPLIER; 
if (intensity_ratio} > 1.0) intensity_ratio = 1.0; 


int intensity = intensity_ratio*32; 
int Lightsourced_color = LightsourcelcolorJCintensity_ratio*32]; 


where color is the palette color of the non-lightsourced pixel, distance is the 
distance to the pixel, and /ehtsourced_color is the palette color that will actually 
be placed on the video display, 

Youll notice that we truncate the value of mtenstry_ratio, so that it can never 
become larger than 1.0 and fmerease the maximum light intensity value. 
Surprisingly, jetensity_ratio not only can go over 1,0, bur it frequently wall, 
depending on the values given to fight_intensity and MULTIPLIER. Setting 
MULTIPLIER to a value greater than 1 (or Aght_intensrty to a value greater than 
32) has the effect of producing a circle of full brightness around the player 
character, which not only looks realistic but will save the player considerable 
eyestrain. 

Before we can create a lightsourced version of the drtw_maze() function, well 
need to create a lightsourcing table and save it in a two-dimensional array. This is 
a task that can take up a lor of CPU time, since it involves searching the entire 
palette 32 times for each of the 256 palette colors to find lightsourced equivalents 
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for those colors. So we'll write a special utility program that will create the table 
and save it to a disk file, Qur ray-casting program can then read the data during 
rts initialization. 

We'll call this utility program MAKELITE.CPP. It will use the doadPCX() 
function to read a PCX file from the disk and will create lightsourcing tables for 
that palette. Thus, if we are going to use the tiles and palette in the file 
IMAGES.PCX in our ray-casting program, and therefore want to base the 
lightsourcing tables on that hle, we can invoke MAKELITE by typing: 


MAKRELITE IMAGES .PCX 


at the DOS prompt. This means that well need to include code at the beginning 
of the main() function of the program to make sure that theres a file name from 
the command line: 
if Carge<2) { 

printf("You must type a filename.\n"); 

exittl); 
I 
Remember that there will always be at least one parameter on the command line: 
the program's file name, Thus we check to see if there are 2 values, the second 
presumably being the PCX fle name. 

We'll also allow the user to pass three optional numeric parameters on the 
command line, after the hile Namic. These Parameters will represent the Career 
values for the red, REC, and blue COMPONCIIeS of the palette colors. If no 
parameters are typed on the command line, these values will default to 0,0,0, 
meaning that we want the palette colors in our lightsource tables to converge on 
the color black as the distance from the viewer increases. However, there will be 
times when we want these values to converge on other colors, such as white or 
blue, for certain special effects. Il talk more about this in a moment. 

We'll first initialize these values to black: 
int redtarget=0; 


int greentarget=0; 
int bluetarget=0; 


then well check to see if alternate values have been typed on the command line. 
lf so, we ll use them: 
af Caragc>=3) redtarget=atoflargvl2]}; 


if (arge>=4) bluetarget=atofCargvl[3]); 
if (arge>=5) greentarget=atoftlargvl[4]); 


The process that follows will be fairly time-consuming, especially on slower 
machines. (It takes about 15 seconds on my 40-mHz 486.) So thar the user wont 
think the computer has locked up, we'll print periodic messages on the display 





CHAPTER ELEVEN Lightsourcing 


explaining what the program is doing. Since the first thing we'll do is load the 
PCX file and extract its palette, that’s what we'll indicate in the first message: 


printf("Loading palette.\n"); 


Well link our well-worn PCX routines to the program, so all we need to do to 
load the file is to call the /oadPCX() function using the command line parameter 


argu/1/as the hle name: 
if (loadPCX(argvl1J,&litepal)) exit(1); 


This loads the file into ftepal, which will need to be declared earlier in the 
program as a PCX_setrwet. (You'll recall that the PCX_struet type ts defined in the 
file PCX.H, which well need to include.) As usual, we check for a valid load, 
exiting the program if /o¢a@PCX tells us that an error has occurred. 

For purposes of claricy, we ll copy the palette from the patette held of the litepal 
structure into three arrays of integer variables, which well call red//, green//, and 
blue!}. Each of these arrays will have 256 entries, one for cach palette color. The 
individual entries will contain the red, green, and blue values for the equivalent 
palette color. Strictly speaking, this step is unnecessary, since we already have 
access to these values in the dtepal structure, But the use of the three arrays will 
make the code that follows clearer. And this ts hardly a time-critical program, 
which will suffer from the extra CPU cycles. Well do the copying with a for/) 
loop: 
for Cint colar=0; color<PALETTESIZE; color++) { 

redLcolort=Litepal.palettelcolor*3J; 

greenCeolorJ=Litepal .paletteCcolor*3+11]; 


blueCcolorJ=Litepal.paletteLcolor*3+2J]; 
} 


The constant PALETTESIZE will be set equal to 256, representing the number 
of colors in the mode 13h palette. This is also done for purposes of clarity, since 
its unlikely that this program will ever be rewritten to handle palettes of a 
different size, 

Now its time to calculate the palerte tables. We'll print a message to the user 
ai) thar they Il know what the Propram iS Up CoO: 


printf("Calculating palette tables"); 


Well perform the palette calculations within a set of three nested for() loops. 
The outer loop will iterate through all 256 colors in the palette. The middle loop 
will iterate through all 33 intensity levels of that color, And the innermost loop 
will once again iterate through all 256 palette colors, searching for the closest 
match for the current color at the current light level. Here's the beginning of the 
outer loop: 


for (coler=0; color<PALETTESIZE; color++) f 
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Since the inner loop will repeat 256 times every time that the middle 
loop executes and the middle loop will execute 32 times for every time the 
outer loop executes (and the outer loop will execute 256 times altogether), the 
innermost instructions (which will contain several time-consuming Hoating point 
operations) will be repeated 256 x 33 x 256, or 2,162,688, times. This is where 
the user is most likely to decide that the program has crashed, so we'll need to 
print something on the screen while all of this is going on. We dont need to 
print mwch — a simple period (.) will do — and we don't need to print it often, 
so we ll just slip this instruction in at the head of the outer loop: 
printt¢’ "o> 


Since this instruction only repeats 256 times, it won't put much drag on the 
execution of the program, But ir will print periods on the display often enough to 
let the user know that the computer hasnt given up the ghost, 

Now we can begin the second loop. This loop will execute 33 times, once for 
every light intensity level: 
for Cint level=0; Level<=MAXLIGHT; Level++) { 


MAXLIGHT is a constant that we'll set equal to the number of light levels, 
which for this program will be 32. Should you decide that you want to 
experiment with a larger or smaller number of light levels, you can redefine this 
constant and recompile the program, Or you can change MAXLIGHT to a 
variable and have the program read its value as a command line value. 

Before we can start searching the palette for the closest equivalent to the 
current color at the current intensity level, we need to calculate the ideal RGB 
values for the lightsourced value of the color. How do we do this? As the middle 
loop repeats 33 times, once for every intensity level, we want to move the RGB 
values of this color in the direction of the target RGB values, which will usually 
be 0,0,0, Since the intensity values cover a range of 32 increments, we'll want to 
increment these values by 1/32nd of the distance between the current RGB 
values and the target values on each iteration of the loop. We can easily find out 
what 1/32nd of the distance would be by subtracting the target values from the 
current values (which we earlier moved to the red/j, green//, and &lve// arrays) 
and dividing the differences by 32. (Actually, we'll divide it by MAXLIGHT, the 
constant we mentioned earlier.) Then we can multiply the differences by the 
CULFEEt Intensity level and add the value of the target color To the result tO hnd 
the ideal RGB values: 
float redlite=(float}(red(CcolorJ-redtarget) / MAXLIGHT * Level + 
redtarget; 


float greenlite=(float) (greenCcolorJ-greentarget) / MAXLIGHT * Level + 
greentarget; 
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float bluelite=(float)}(blueLeolort-bluetarget? / MAXLIGHT * Level + 
bluetarget; 


The ideal lightsourced RGB values for the current palette color at the current 
intensity are now stored in the Hoating point variables redlite, greeniite, and 
blueltte. Most of the time, there will be no perfect fit for these intensities in the 
256-color palette. (As | mentioned earlier, these values may not even be whole 
numbers.) So we have to search the palette to find the closest ft. We'll do this by 
assigning a proximity score to each palette color, with lower scores indicating 
closer matches than higher scores. The color with the lowest score will be 
assigned as the lightsourced value for the current color at the current intensity. To 
determine which score is lowest, well maintain a floating point variable called 
bestscore, which will hald the lowest score of all the palette colors so far searched. 
[fa lower palette color is found, bestscore will be assigned that value instead. We'll 
initialize bestscore by setting it to the highest possible Hoating point value, higher 
than any possible score that will be assigned to a palette color, so that it will 
immediately be replaced by the score of the first color in the palette: 


float bestscore=MAXFLOAT; 


MAXFLOAT is a constant defined in the header fle VALUES.H that represents 
the largest possible Hoating point number that the compiler can handle. 

To perform the search, well iterate (again) through all of the palette colors: 
for Cint color2=0; color2<PALETTESIZE; colore++) { 


Calculating the proximity score for a palette color isn't hard. We can find the 
proximity scores for the individual RGB values of a color simply by subtracting 
those RGB values from the ideal RGB values that we stored in redlite, greentite, 
and blueltte: 
redscore=tabs(red[(color2J-redlite); 


greenscore=fabs(green[color2J-greenlite); 
bluescore=fabs(blueCcolor2J—bluelite); 


Notice that we use the fabs/) function (defined in the standard header file 
MATH.H) to get the absolute value of the differences, since only the distance 
berween the values matters, not the direction of thar distance. We don’t care if the 
RGB components are brighter or darker than the ideal values, only that the 
ditterence is relatively small. To calculate an overall proximity score for this color, 
we add the proximity scores for the RGB values: 


float score=redscore+greenscoret+bluescore; 


Is this score better (that is, smaller) than the previous best score? 


it (score<bestscore) f{ 
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If it is, we replace the previous best score: 


bestscore=score; 


Its not enough simply to save the best score, of course. We also need to 
remember which palette color received that score. We'll be placing the 
lightsourcing data in a two-dimensional array called Hresowrce/}//, which will be 
defined at the beginning of the program. So we might as well go ahead and place 
the number of the top-scoring palette color in the entry of that array 
corresponding to the current level and color, If another palette color gets a better 
score, the number of that color will replace this one: 

LitesourceLlevellCcolorJ=color2; 
, 
} 
} 
} 
That not only ends the #ff) statement but all three of the nested loops. When we 
reach this point in the program, the lightsourcing array will have been 
completed. So let's write it to the disk. We'll let the user know whats happening: 
printf("\nWriting LITESORC.DAT.\n"); 
Then well open a file called LITESORC.DAT to stuff the data into: 


1f (Chandle=Topen("litesorc.dat","wb"}J==NULL) f 
perror("Error'); 
exit; 


+ 
This will terminate the program if an error occurs. The perrer() function, the 
prototype for which is in the standard header fle FCNTL.H, will print the word 
“Error: followed by a. colon and cl message explaining the nature of the CITT, 

If all goes well up to this point, we can write the contents of the éitesource[/|/ 
array to the file with a single instruction: 
fwrite(litesource,MAXLIGHT+1,PALETTESIZE,handle) ; 

All that remains is to close the hile, let the user know that everythings hunky 
dory, and terminate the min() function: 


fcloseChandle); 
printf("Done! \n"); 
} 


The MAKELITE.CPP Program 
The complete text of the MAKELITE.CPP program appears in Listing 11-1. 
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= Listing 11-1 The MAKELITE.CPP program 


ff 
// MAKELITE.CPP 
ff 


ff Utility for generating Lightsourcing tables. 
‘/ Written by Christopher Lampton 

‘/ for Gardens of Imagination (Waite Group Press) 
fi 


#include <stdio.h> 
Finclude <math.h> 
Finclude «stdlib.h> 
f#include <values.h> 
Finclude <conio.h> 
Finclude «10.h> 
Finclude <fentl.h> 
Finclude "“pex.h" 


const MAXLIGHT=32; 
const PALETTESIZE=256; 


pex_struct Litepal; 

int redLPALETTESIZE],greenCPALETTESIZEI, 
bluelPALETTESIZE; 

unsigned char LitesourceCMAXLIGHT+1 JCPALETTESIZE); 

float redscore,qreenscore,bluescore; 

FILE “handle; 


void mainCint argc,char* argvLlJ]) 
{ 


ff Set default target to black: 
int redtarget=U; 

int greentarget=0; 

int bluetarget=0; 


‘/ Check for filename on the command line: 
if (arge<2) f 
printf("You must type a filename. \n"); 
exit(1); 
} 


‘/ Check for target values on command Line: 
if Carge>=3) redtarget=atoflargvi2]); 

if Carge>=4) bluetarget=atoflargv(3]); 

if Carge>=5) greentarget=atoflargvl4]); 


(Ounhued oy WeRr pape 
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conned Frevn pres Nihal poerete 
if Let user know what's going on: 
printt("Loading palette. \n"); 


/*f Load the PCX file: 
if ClLoadPCxkCargv£L11,&litepal)) exitt1): 


// Copy palette to RGB arrays: 

for Cint color=0; color<PALETTESIZE; color++) f 
redLeolorJ=Litepal .palette[color*3J; 
greenlcolorJ=Litepal.paletteCcolor*3+1]; 
blue(colorJ=Litepal palettelcolor*3+2]; 

} 


ff Let user know what we're about to do: 
printt("Calculating palette tables"); 


ff Iterate through all 256 palette colors: 
for (color=0; color¢PALETTESIZE; color++) f 


ff Let user know we haven't died: 
ar intte’ 3s 


/f Iterate through all 3241 intensity Levels: 
for Cint Level=0; Level<=MAXLIGHT; lLevel++) { 


/f Caleulate ideal Lightsourced RGB values: 

float redlite=(float)(redicolord-redtarget) | MAXLIGHT 
* Level + redtarget; 

float greenLite=(float) (greenLcolorJ—-greentarget) # MAXLIGHT 
* Level + greentarget; 

float bluelite=(float)(blueCcolor]—bluetarget) / MAXLIGHT 
* level + bluetarget; 


ff Initialize score to very large number: 
float bestscore=MAXFLOAT; 


ff Search the palette for closest match: 
for (int color2=0; color2<PALETTESIZE; color2++) { 


ff Assign proximity score to color: 
redscore=fabs(redLcolor2J-redlite); 
greenscore=fabs(greenCcolor2J-greenlite); 
bluescore=fabs(blue[color2J-bluelite); 
float score=redscore+greenscoretbluescore; 


// Is this better (i.e. smaller) than previous best? 
if (score<bestscore) ¢ 


‘/ If so, replace best score: 
bestscore=score; 


‘ff And remember which color got it: 
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Litesourcellevel JCcolorJ=coloré; 
+ 
} 
} 
} 


ff Tell user that the worst 15 over: 
printf’ \nWriting LITESORC.DAT.\n"); 


‘f Try to open disk file: 

if (Chandle=fopen("lLitesore.dat’,"wb"}I==NULLI ¢ 
perroart"Error"): 
exit; 


} 


ff If successful, write Lightsource tables to file: 
fwrite(lLitesource ,MAXLIGHT+1,PALETTESIZE, handle); 


‘/ Close up shop: 
feloseChandle); 


‘f And tell the user to breathe easy: 
printf( "Done! \n"); 


Using the Lightsourcing Tables 


Now that weve got the light source data, what are we going to do with tt? Earlier, 
I showed you the instructions necessary for calculating the color of a pixel based 
on its distance from the viewer using the lightsourcing equation and the light 
source tables. The light source tables save us from having to perform a time- 
consuming search of the paletre before we write a pixel to the display, bur even 
the relatively simple lightsourcing formula, which contains a division and a 
multiplication, is too time-consuming to perform while ray casting is in progress, 
since it must be performed for every pixel in the viewport. So, in order to further 
reduce the time required to perform lightsourcing on a pixel, we'll place the 
results of the lightsourcing formula in a second array, which we'll call ditelevel/'/. 
There will be one entry in this array for every possible distance that a pixel can be 
from the viewer, representing the intensity of the light (on a scale of 0 to 32) at 
that distance. In a maze with GRIDSIZE squares across and down, where each 
square is 64 by 64 pixels in size, the maximum possible distance will be 
GRIDSIZE x 64, which will cover the case in which the viewer is on one side of 
the maze looking toward the far side, In the 16 by 16 mazes we've used so far in 
this book, there would need to be 4,096 entries in this array. Since there are only 
33 possible light intensities, we can use an wasigned char array, which will only 
take up 4 kilobytes of memory. Cheap at the price. 
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Calculating the values in the fitelevel// array will take a lot less CPU time than 
calculating the lightsourcing values for each palette color, but its still sufficiently 
time-consuming that well want to get it our of the way during program 
initialization. For that reason, we wont put it in the @raw_maze() function, but 
will require the calling program to calculate it and pass a pointer to draw _maze() 
as a parameter. So were going to deviate this one time from the tradition that we 
established much earlier in this book of writing the drau_maze(} function and 
then writing a small demo program to call it. Instead, well write the demo 
program first. 

This demo program will be based on the RAYDEMO.CPP program from 
chapter 9, I'll only discuss the differences between this lightsourcing demo, 
which well call LITEDEMO.CPR. and the earlier demo. The major difference 
will be the calculation of the /ttelevel() array. The array will be declared like this: 


unsigned char *LiteLlevel; 


Before we can calculate the values, we must allot space for the data: 
Litelevel=new unsigned charCMAXDISTANCE); 

Earlier, well initialize the constant MAXDISTANCE to the maximum 
possible distance that a light ray can travel through the maze: 
const MAXDISTANCE=64*GRIDSIZE; 

The data will be calculated in a for() loop, which will iterate through all 
possible distances: 


for Cint distance=1; distance<MAXDISTANCE; distancet++) 
Next, we apply the lightsourcing formula that | described a few pages ago: 


float intensity_ratio=(float)intensity/distance*MULTIPLIER; 
if (intensity_ratio=1.0) ratio=1.0; 
LitelLevelCdistancel=ratio*MAXLIGHT; 

} 


We now have an array of light intensities for all 4,096 distances. 
We'll also need to load the lightsourcing tables into the array from the disk fle 
that MAKELITE.CPP stored them in. We'll declare the array like this: 


unsigned char LitetableCMAXLIGHT+1 ICPALETTESIZE1; 


The instructions for loading the array are almost identical to those that we 
used in MAKELITE.CPP to save it: 
if (Chandle=fopen("Litesorc.dat","rb"JJ==NULL) f 


perror("Error"); 
exit; 
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fread(lLitetable ,MAZLIGHT+1 ,PALETTESIZE, handle); 
felose(handle); 


Up until now, weve given the user the option of placing a floating point 
number on the command line to represent the desired viewing angle. This time, 
let's give the user a couple of additional options: 
if (arge>=2) viewing_angle=atof(Cargvl1J]); 


if Carge>=5) intensity=atoflargvl2]); 
if Carge>=4) ambient_lLevel=atof(argvl3]); 


The first line checks for the viewing angle parameter and reads it off the 
command line if its found, The second line loads a value for the intensity of the 
light source (which we'll set to 32 — full brightness — by default). The third 
line reads the ambient lighting level. We mentioned ambient lighting in the 
chapter on ray tracing. Ambient light is light that appears to come from all 
directions at once, hiling shadows with a certain minimum light level. We'll add 
the ambient light level to all pixels on top of the light received from the player's 
“torch,” bur will nor let the overall light level exceed 32. An ambient level of 0 
will make the room appear to be lit only by the torch. A level of 32 will make all 
surfaces appear the way they would in full light (that is, the way they did in the 
ray-casting chapter). You can tweak the ambient value to levels in berween these 
rwo to find the level you like best. Even in the darkest dungeon a small ambient 
level is desirable: otherwise the screen will nurn pitch black if the players torch 
should go out. Of course, that may be the effect that you're looking for. 

Finally, the call to our lightsourced version of the draw _maze() function will 
look like this: 
draw_maze(lwalls,flor,ceiling,screen,xview,yview, viewing angle, 

Viewer_height,ambient_level,textmaps. image, 
Litetable,litelevel); 

This is similar to the way in which the ray-cast version in chapter 9 was called, 
with the familiar pointers to the wells/}, flor[/, and cetling// arrays, but we've 
added pointers to the /itetable and Jitelevel arrays. 


The LITEDEMO.CPP Program 
The complete text of the LITEDEMO.CPP program appears in Listing 11-2. 





Listing 11-2 The LITEDEMO.CPP program 


// LITEDEMO.CPP 
if 


CoRraieS OF Ret pe 
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comtineed from previons pape 

‘/ Calls ray=casting function to draw Lightsourced 
‘/ view of maze. 

| 

ff Written by Christopher Lampton for 

‘/ Gardens of Imagination (Waite Group Press) 


Rinclude <stdio.h> 
RFinclude <dos.h> 
#include <conio.h> 
Finclude <stdlib.h> 
finclude <math.h> 
Rinclude "sereen.h" 
#include "“"pcx.h" 
#include “Litesorc.h" 


const GRIDSIZE=16; 

const MAXDISTANCE=64*GRIDSIZE; 
const NUM_IMAGES=15; 

const float MULTIPLIER=3; 


pex_ struct textmaps; 

FILE *handLle; 

unsigned char LitetablelMAXLIGHT+1JCPALETTESIZEJ; 
unsigned char *litelevel; 


map_type walls=f 

tS Sr Se Fe De Be Fe Se Fe Sp Se Se Se De Fe ST, 
{7 §..0; §:0, 0,0. 2 0 8 00,0, 0, 0 $3, 
ti: #, G,- 04) 0,:0, 0,.03.0, 35-0, 0,0, 0, 0,0, 53; 
Lf, &, 8.) G,.-8,0,. 8,0, G6, 8,..0,0,.0, 8, 53, 
{ 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 4, 0, 0, 0, 31, 
fi2, 0, 0, 0; 0; 0, 0. 0. 0, '0.11,11, 0.0, 0, 53, 
Lit, 0,0, G,.0, 0,0, 0, 0,0, 0,31,10,.0, 0, 5), 
Cit, 0,8, G0; 0,-0.0, G0, 8,0, 10,0, 8, SF, 
f14. 7, 7, 6. 0: 0. 6: 0; 0, 0. 0:11.10, 0; 0, 5%, 
{i2, 0, 0; 0,0, 0, 0, 0, 0, 0,119,711, 0,0, 0, 53, 
Lie, 5. te Oy. Be Oy. oe te Oo, OE 0. Ae Se 
{ 7, 0, 0, 0, 0, 0, 0, 1, G0, 1, 0, 0, 0, 0, 0, 31, 
{ 7, 0, 0, 0, 0, 0, 0, 1, O, 0, O, 0, BD, 0; 0,123, 
ff, 0,0, 0,-0,-0,.8, 4%, 01, 0), 8,0, 0.-0,183, 
tf, 6,6, 6, 6, 0, 0,-1, 0,1, O,..0,:.0,.0, 8,103, 
{fp Sp Sp Fp Sp ae 9215,15,15, Se Se Fe Dy 3, 3 

}; 

ap_type flor=f{ 

{ 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5» 5, 5, 53, 
{i 5, 5,.%, 5,.5,°5,-5, 5, 5,5, S$». 5, $5 5, 5) 53 
Sp ae ae Spa ee e Secdae e op ate ay aoe 
{5, 5, 5, 5, 5, 5, 5, 5, 5,5, 5,5, 5,5, 5, 5}, 
(5. 5, 5 5, 8,5, 5,5, 5, 5, 5, 5, 5,5, 5, 53, 
Mp Dig ie Chap i le he ie Bip le pe ae ae elie eee 
{ 5, 5, 8, 8, 8, 8, 8, 3, 35 34 Jy Fe Se Je Je Shy 
{ 5. 5.5. 8. 8:8, 5; 5, 5,5, 5, 8; 5)55.5, 53 
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}; 


map_type ceiling={ 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13}, 
£13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13), 
£15,135, 15, 13, lay iay lop lop oe op lop oe op lo, lop sp 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13}, 
{13,13,15,13,13,13413,15,15, 15,145,135, 13713, 135,13), 
£15,135, 13,135,135; 157 lo. lop lag lop lop lop los lop oy lod, 
£13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13}, 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13}, 
115,13, 15; 15, 13) lay lop oy oy bop lo oe lop 1, lop bod, 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13}, 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13), 
£15, 135,13,13,135,135,135,15,13, 15,135,135, 14,15,135, 13); 
{13,13,13,13,13,13,13,13,13,;13,13,13,13,13,13,13}, 
{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13), 
£15,15,15,513, 15,155 1315,15,) 155 lo, lay bos 15, | oy oe, 

{13,13,13,13,13,13,13,13,13,13,13,13,13,13,13,13) 

fy 


float viewing _angle=3.14; 
float intensity=MAXLIGHT; 
int viewer_height=32; 

int ambient_level=0; 

int xview=8*64+32; 

int yview=8"64+32> 


void mainCint argc,char* argvlJ) 
{ 
‘/ Read arguments from command Line if present: 
if Carge>=2) viewing_angLle=atoflargvl1J); 
if Carge>=3) intensity=atoflargvl2]); 
if (arge>=4) ambient_level=atoflargvl3]); 


‘/ Load texture map images: 
if (loadPCX("images.pcx",&textmaps)) exit 1); 


// Load Lightsourcing tables: 
if (Chandle=fopen("Litesore.dat","rb")J3==NULL) f 
perror("Error’); 
exit; 
} 
fread(litetable,MAXLIGHT+1,PALETTESIZE,handle) ; 
Tclose(handle); 


CoH hued oe Meee poled 
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confinned from previeus pape 
‘/ Initialize array of light levels: 
LitelLevel=new unsigned charCMAXDISTANCE]; 


if Calculate Light intensities for all possible 

// distances: 

for Cint distance=1; distance<MAXDISTANCE; distance++) { 
float ratio=(float)intensity/distance*MULTIPLIER; 
if (ratio=1.0) ratio=1.0; 
LitelevelCdistancelJ=ratio*MAXLIGHT; 
int dummy=0; 

} 


// Point variable at video memory: 
char far *screen=(char far *)JMK_FPCOxa000,0); 


// Save previous video mode: 
int oldmode=*(int *)MK_FPCOx40,0x49) > 


// Set mode 13h: 
setmode(Ox13); 


// Set the palette: 
setpalette(textmaps.palette); 


ff Clear the screen: 
cels(screen); 


/f Draw a ray-cast view of the maze 

draw_maze(walls,flor,ceiling,screen, xview, yview,Viewing_angle, 
viewer_height,ambient_Level,textmaps. image, 
litetable, litelevel): 


‘/ Wait for user to hit a key: 
while (!kbhit)); 


// Release memory 
delete textmaps. image; 
delete Litelevel; 


// Reset video mode and exit: 
setmodeloldmode) ; 


Ligntsourcing in Three Lines or Less 
The prototype for the function, which will go in the file LITESORC.H, looks 
like this: 
woid draw_maze(map_type map,map_type floor,map_type ceiling, 
char far *screen,int xview,int yview, 


float viewing_angle,int viewer_height, 
int ambient_lLevel,unsigned char far *textmaps, 
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unsigned charCMAXLIGHT+1 JCPALETTESIZE), 
unsigned char *Litelevel); 

The function itself is in the fle LITESORC.CPP. It is nearly identical to the 
ray-cast version of the d@ntw_maze() function in chapter 9. All that has changed, 
other than the prototypes, are the lines that actually place data on the display. 
Instead of simply copying the pixel data from the rexture-map buffer to video 
RAM, we'll do something slightly more complicated. We'll use the distance 
variable (which contains the distance, in Hoor pixel units, from the viewer to the 
pixel being drawn) as an index into the /fefevel array to find the light level for 
that distance, then add the ambient term to that value: 


int Level=Litelevelldistance ]+ambient_lLevel ; 


Since the ambient term may take this value over 32, we'll chop it off in that 
level: 


if Clevel>MAXLIGHT) Level=MAXLIGHT; 


The constant MAXLIGHT is assigned a value of 32 in the LITESORC.H fle, 
should we be overcome with an urge to change the number of light levels. 

Now thar we have the light level, we can use it as an index into the 
litesource[|/) array to find the lightsourced color for the current pixel. We'll use 
the non-lightsourced color for the pixel, which is at offset frleprr in the textmaps|/ 
array as the second index for this two-dimensional array. Then well copy the 
resulting value into video RAM: 


screenlLoffsetJ=Litesourcel level J[textmapsltileptrJd; 


The draue_maze() function writes pixels to the display in three different places, 
Once when drawing the walls, once when drawing the Hoors, and Once when 
drawing the ceiling. Well use these same three lines of code in all three places. 
And those, believe it or not, are all the changes that are necessary to add 
lightsourcing to the core of our ray-casting engine. By placing all of the tough 
work in the calling module and in the MAKELITE program, we ve actually lett 


very little extra work tor dmw_mazel) to do. 


The Lightsourced draw maze() Function 


The lightsourced version of the draw_maze() function appears in Listing 11-3. 





Listing 11-3 The lightsourced draw_maze() function 


// LITESORC. CPP 


ff coral on AEN ere 
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cominucd from previocs page 

‘/ Function to draw lightsourced walls, floors and 
// ceilings using ray casting. 

f/f Written by Christopher Lampton for 

// GARDENS OF IMAGINATION (Waite Group Press). 

ff 


Finclude <stdio.h> 
Finclude <math.h> 
Ainclude “Litesore.h" 
Hinclude "pox.h" 


ff Constant definitions: 


const WALL_HEIGHT=64; ff Height of wall in pixels 
const VIEWER_DISTANCE=192; // Viewer distance from screen 
const VIEWPORT _LEFT=0; f/f Dimensions of viewport 


const VIEWPORT_RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT_BOT-VIEWPORT_TOP; 
const VIEWPORT_CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/2; 
const GRIDSIZE=16; 

const MAXDISTANCE=464*GRIDSIZE; 


void draw_maze(map type map,map type floor,map type ceiling, 
char far “screen, int xview, int yview, 
float viewing_angle,int viewer_height, 
int ambient_level,unsigned char far * textmaps, 


unsigned char LitesourceC(MAXLIGHT+1JLPALETTESIZEJ, 


unsigned char *lLitelevel) 


/f Draws a ray-cast image in the viewport of the maze represented 
/f in array MAPCI, as seen from position AVIEW, YVIEW by a 

‘/ viewer Looking at angle VIEWING_ANGLE where angle 0 is due 

// north. (Angles are measured in radians.) 


{ 

ff Variable declarations: 

int sy,otfset; ‘/ Pixel y position and offset 
float xd,y¥d; ‘/ Distance to next wall in x and ¥ 
int gria_x,grid_y-: ‘/ Coordinates of x and y grid lines 
float “cross_x,xcross_y; ‘/ Ray intersection coordinates 
float ycross_x,ycross_y; 

unsigned int xdist,yvdist; ff Distance to x and y grid Lines 
int xmaze,ymaze; ‘/ Map Location of ray collision 
int distance; ‘/ Distance to wall along ray 

int tmecolumn; ‘/ Column in texture map 


float yratio; 


/f Loop through all columns of pixels in viewport: 
for (int columm=VIEWPORT LEFT; columm<VIEWPORT_RIGHT; column++) { 


‘f/f Calculate horizontal angle of ray relative to 


t | | 


| 
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ff center ray: 
float column_angle=atan( (float) (column-160) 
/ VIEWER _DISTANCE): 


// Calculate angle of ray relative to maze coordinates 
float radians=viewing_anglet+column_angLle; 


‘* Rotate endpoint of ray to viewing angle: 
int x2 = -1024 * (Csin(radians)); 
int y2 = 1024 * (cos(radians)); 


‘/ Translate relative to viewer's position: 
M2+=xView; 
yet=yview; 


‘/ Initialize ray at viewer's position: 
float x=xview; 
float y=yview; 


‘/ Find difference in x,y coordinates along ray: 
int xdiff=x2-xview; 
int ydift=y2-yview; 


ff Cheat to avoid divide-by-zero error: 
if (xdiff==0) xdifft=1; 


‘/ Get slope of ray: 
float slope = (floatiydiff/xdiff; 


ff Cheat Cagain) to avoid divide-by-zero error: 
if (stope==0.0) slope=.0001; 


ff Cast ray from grid Line to grid Line: 
for C23) ¢ 


ff If ray direction positive in x, get mext «x grid line: 
if (xditf=0) grid_x=(Cintdx & Oxf fcO)+64; 


‘f/f If ray direction negative in x, get last « grid Line: 
else grid_x=(Cint)x & OxffcO) - 1; 


// If ray direction positive in y, get next y grid Line: 
if Cydiff>0) grid_y=(Cintiy & OxffcO) +64; 


/f If ray direction negative in y, get last y grid line: 
else grid_y=(Cint)y & OxffcO) - 1; 


ff Get x,y coordinates where ray crosses x grid Line: 
xCrOSS x=grid_x; 


xcross_y=ytslope*(grid_x-x); 


// Get x,y coordinates where ray crosses y grid Line: 


COMMIT OF KT Batre 
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continued from previnus pete 
yeross x=x+(grid_y-y)/slope; 
yeross_y=grid_y; 


/* Get distance to x grid Line: 
x0=xcross x—-x; 

yYo=xcross_y¥=¥; 
xdist=sqrt(xd*xd+yd"yd) > 


‘i Get distance to y grid Line: 
ud=ycross_xX=x; 

yd=ycross_y-y; 
ydist=sqrt(xd*xdt+tyd* yd); 


‘f If x grid line is closer... 
if (xdist<ydist) f 


‘f Calculate maze grid coordinates of square: 
KMaze=xeross_ x“/O64; 
ymaze=xcross_ y/64:; 


‘/ Set x and y to point of ray intersection: 
M=NCroSs x; 
Y=XCross_y; 


ff Find relevant column of texture map: 
tmcolumn = Cint)y & Ox3t; 


// Is there a maze cube here? If so, stop Looping 
if (mapCxmazellymazel) break; 

} 

else i // If y grid line is closer: 


/f Calculate maze grid coordinates of square: 
xMaze=ycross_x/64; 
ymaze=ycross_y/é4; 


// Set x and y to point of ray intersection: 
x=Vcross x; 
y=yCcross_y; 





ff Find relevant column of texture map: 
tmeolumn = Cintdx & Oxf; 


jf Is there a maze cube here? If so, stop Looping: | 
if (maplxmazellymazel]) break; 
} 
} 


// Get distance from viewer to intersection point: 
Md=KX—xXVIEWS 

yd=y-yview; 
distance=(long)sqrt(xd*xd+yd*yd)"cos(column_angle); 
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if (distance==0) distance=1; 


ff Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 


ff Calculate bottom of wall on sctreen: 
int bot = VIEWER_BDISTANCE * viewer_height 
/ distance + VIEWPORT_CENTER; 


ff Calculate top of wall on screen: 
int top = bot - height + 1; 


/f Initialize temporary offset into texture map: 
int t=tmcolumn; 


ff If top of current vertical Line 15 outside of 
// wiewport, clip it: 


int dheight=height; 

int iheight=IMAGE_HEIGHT; 

¥ratio=(float WALL _HEIGHT/height; 

if (top < VIEWPORT_TOP) ¢ 
dheight-=(VIEWPORT_TOP - top); 
t+=Cint) ((VIEWPORT_TOP-top)*yratio)*320; 
jheight <= ((VIEWPORT_TOP=top)*yratio); 
top=VIEWPORT_TOP; 

} 

if (bot > VIEWPORT_BOT) f 
dheight -= (bot — VIEWPORT_BOT): 
jheight -= (bot — VIEWPORT_BOT)*yratio; 
bot=VIEWPORT_BOT; 

} 


// Point to video memory offset for top of Line: 
offset = top * 320 + column; 


ff Initialize vertical error term for texture map: 
int tyerror=64; 


ff Which graphics tile are we using? 
int tile=mapCxmazellymazel-1; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tiless) 
*IMAGE WIDTH+t; 


‘/ Loop through the pixels in the current vertical 
ff Line, advancing OFFSET to the next row of pixels 


‘i after each pixel is drawn. 
for Cint h=0; h<iheight; h++) { 


// Are we ready to draw a pixel? 


contend on met fae? 
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} 


while (tyerror>=IMAGE HEIGHT) f 


‘/ If so, draw it: 

int level=LitelevellCdistancel+ambient_lLevel; 

if Clevel>MAXLIGHT) Level=MAXLIGHT; 
screenLoffsetJ=litesourcelL level JLtextmapsltileptrJi; 


‘// Reset error term: 
tyerror-=IMAGE_HEIGHT; 


ff find advance OFFSET to next screen Line: 
offset+=320> 
} 


ff Incremental division: 
tyerror+=height; 


// Advance TILEPTR to next Line of bitmap: 
tileptr+=320; 


ff Step through floor pixels: 
for (int row=bot+1; row<=VIEWPORT_BOT; rowt+) f{ 





/*f Get ratio of viewer's height to pixel height: 
float ratio=(floativiewer_height/(row-100); 


/f Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/ cos(column_angle); 


// Rotate distance to ray angle: 
int x = - distance * (sin(radians)); 
int y = distance * (cos(radians)); 


‘/ Translate relative to viewer coordinates: 
KF=KVIEW! 
Yt=yV1eW; 


// Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 


‘/ Find relevant column of texture map: 
int t = CCint)y & Ox3t) * 320 + CCintix & OnSt): 


/f Which graphics tile are we using? 
int tile=floor[xmazel]lLymazel; 


‘/ Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*IMAGE_HEIGHT+(tilexs) 
*TMAGE_WIDTH+t; 





} 


CHAPTER ELEVEN Lightsourcing 


‘/ Calculate video offset of floor pixel: 
offset=row*320+column; 


ff Draw pixel: 

int Level=litelevel Cdistancel+ambient_Level; 

if (Level>MAXLIGHT) Level=MAXLIGHT; 
screenLoffsetl=litesourceClevell][textmapsCtileptrd; 


f/f Step through ceiling pixels: 
for (row=top-1; row>=VIEWPORT_TOP; --row) f 


ff Get ratio of viewer's height to pixel height: 
float ratio=(float) (WALL_HEIGHT-viewer_height)/(100-row) ; 


ff Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


ff Rotate distance to ray angle: 
int x = = distance * Csin(radians)}; 
int y = distance * (cos(radians)); 


ff Translate relative to viewer coordinates: 
Xt=xVIeW,; 
yt=yview; 


// Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 


// Find relevant column of texture map: 
int t = (Cintiy & Ox3f) * 320 + (Cintix & Ox3f); 


/f Which graphics tile are we using? 
int tile=ceilingl xmazel]Dymaze]; 


/f Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tilexr5) 
*IMAGE_WIDTH+t: 


/f Calculate video offset of floor pixel: 
of fset=row*320+column; 


// Draw pixel: 

int lLevel=LitelevelCdistancel+ambient_level ; 

if Clevel>MAXLIGHT) Level=MAXLIGHT; 
screenLoffsetlJ=Litesourcel level J[textmapsCtileptrJ]; 
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To run the program, go to the LIGHT directory and type LITEDEMO. You'll 
see the familiar view of the ray-cast maze from chapter 9, but this time much of 
it will be shrouded in gloomy shadows (see Figure 11-5), Try tooling around with 
the intensity and ambrent_level parameters to sée what effect they have, 
(Remember that the first parameter on the command line is the angle, followed 
by the intensity and ambient parameters, in that order.) Type LITEDEMO 0 0 
to see the maze in no light at all. Whoops, the screen is completely black! Not 
much reason to include a screen shot of that one. And LITEDEMO 0 32, where 
the ambient is turned up all the way, looks exactly like the screen shots at the end 
of chapter 9. Bur LITEDEMO 16 0 shows a spookier and darker dungeon (refer 
to Figure 11-6). And LITEDEM®O) 4 shows a dungeon made up of little besides 
shades of dark gray (Figure 11-7). 

A little bit of ambient light can go a long way. Try LITEDEMO 32 4 to see 
the maze with a bright torch and some dim ambient lighting. Bur LITEDEMO 
32 16, which raises the ambient level halfway to full brightness, doesn't look 
much different from the maze in full light. | 


Alternate Lightsourcing Effects 


You dont have to use lightsourcing in your programs. Many popular maze games, 


such as Wolfenstein 3D, use no lightsourcing effects at all and still manage to 





Figure 11-5 A gloomy maze produced Figure 11-6 Turning down the intensity 
by LITEDEMO. EXE 
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Figure 11-7 Almost in total darkness 
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enthrall players. But it’s a nice special effect to use when you want to add 
something a little extra to your code. The best thing about using the 
MAKELITE program to generate lightsourcing tables is that you can use it with 
almost any palette whatsoever, not just with special palettes designed to work 
with lightsourced graphics. Of course, some palettes work better with this 
lightsourcing method than others. Since all the palette colors converge on black 
and dark gray at low light levels, it helps if there are several dark gray and brown 
colors in the palette. Otherwise, severe banding can occur in very low light, all 
colors being converted to one or two very dark colors by the lightsourcing 
routines. 

Lightsourcing can be used with some special effects that you might not have 
thought had anything to do with light levels. The game Shadowcaster, from 
Origin Systems, uses lightsourcing to pull off some unexpected effects, such as 
scenes hilled with fog (see Figure 11-8) and and underwater scenes (Figure 11-9). 
Irs not hard to figure out that these must have been done with lightsourcing 
tables similar to the ones weve learned to create in this chapter. However, where 
the lightsourcing tables thar we created for our demo program are based on a 
target color of pure black (with RGB values of 0,0,0), these fog and underwater 
effects must be based on lightsourcing tables with target values of white 
(63,63,63) and blue (0,0,63). 

You can easily create a fog table with the MAKELITE utility, by going to the 
LIGHT directory and typing: 

MAKELITE 63 63 63 


Once the table is complete, run LITEDEMO again. This time the maze will 
be enshrouded with mist, as in Figure 11-10. To try and duplicate the 
underwater effect, Type: 


MAKELITE 0 0 63 





Figure 11-8 A scene from Ongin’s Figure 11-9 Another scene from 
Shadowcaster, demonstrating how Shadowcaster, with underwater lighting 
lightsourcing can create fog effects effects 
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Figure 11-10 A mist-enshrouded maze 
created by usina lightsource target 
Values of 63.63.65 


This eftect is a bit less successful. Rather than appearing to be underwater, the 
maze appears to be enshrouded in b/we fog this time. Typing LITEDEMO 6& 0, 
which decreases the circle of light around the player, helps a bit, but too much 
detail ts lost in the distance. To get a better underwater effect, you might take a 
tip from Shadowcaster and design a set of underwater texture-map tiles in which 
the color blue already predominates, with swirling lines that suggest light 
refracted through a wavy surface. 


Lightmapping 


In real life it’s rare to find a room that is illuminated entirely by a light source at 
the viewers position, but neither are all scenes lit entirely by ambient light. Just 
as often, lighting comes from multiple light sources scattered about in various 
positions, some of them bright and some of them not so bright, some of them 
stationary and some of them moving. Your living room, for instance, may be 
illuminated by two or more table lamps, and possibly by an overhead lamp as 
well, And even when these sources have been turned off, light may pour in from 
windows or nearby rooms. All of these sources of illumination may periodically 
change from dim Toh bright and back again and may even Move around in rhe 
course of the day. (The light streaming through the window, for instance, may 
enter at one angle in the morning and another in the evening.) If our ray-casting 
engine is to accurately model the kind of illumination found in the real world, it 
will have to model the distribution of variable local light sources throughout the 
maze. And the best way I know to model this distribution is through the use of 
lightmaps. 

Just as a heightmap specifies the floor height at various points throughout the 
maze, a lightmap specifies lighting intensities. This can be done for every pixel in 
the maze or it can be done on the level of the maze grid. The first system, which 


i ——- | 
a 
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is the simpler of the two, could be called block-aligned lightmapping, by analogy 
co the block-aligned heightmaps we talked about in chapter 10. And the 
lightmaps themselves look a lot like heightmaps. Here are the lightmaps we ll use 
in our demo program: 


map type floorlites={ 


{ 0, 0,.0, 0,-0, 0, 0,.0, 0,0, 0, 0, 0, 6, 0,0, 
{ 0, 0, 0, 0, .0,:0, 0, 0, 0, 0, 0,0, 0, 0, 0, 03, 
£0; 0, 0) 0,0; 6, 0,-0, 0,0, D0, 0, 0, O,:0;) UF, 
(32, 0, 0, 0, 0, 0, 0,-0, 0,0, 0, 0, 0, 0, 0, Of, 
{ 0, 0,0, °0, 6,:0, 0,0, 0, 0,0, 0, 0, 0, 0, 0}, 
£0, 0,0, 0; 0,0; 0,0; 0,0, 6,0, 0, 0;.0, OF, 
{ 0, 0,.0,16,16, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, GI, 
{ 0, 0, 0,16,16, 0, 0, 0, 0, 0, 0, G, 0, 0, 0, OI, 
{ 0,32, 0, 0, 0. oO, 0, 0, 0, 0, 0, 0, 0, 0; 0, OF; 
(32,32,32, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, :0, OF, 
£°0,32, 0, 0, 0, 0, 0,.0, 0,0, 0, 0, 0, 0, 0, OG, 
{ 0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 
{ 0, 0, 0, 0, 0, 0, 0,32,32,32, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0,32,32,32, 0, 0, 0, 0, 0, O}, 
£0, 0, 0, 0, 0, 0, 0,32,32,32, 0, 0, 0, 0,.0, 0}, 
{ 0, 0, 0, 0, 0,0; 0, 0,32, 0, 0, 0, 6, 6, 0, 0} 
4; 


map type ceilinglites=f 


i 6, 0, 0, 0, 0, 0, 0,:0, 0, 0, 0, 0, 0, 0, G, OF, 
iG, 0,0, 0,:0;: 8, 6:6, 0, 0, 8, 3,°0, 6,0, GF, 
{ O, 0,.0, 0,.0, 0;. 0,0, 0,.0, 0, 0,0, 0, 0, 0, 
{i 0, 0, 0, 0, 0, 8, 0,0, 0, 0, 0, 0, 0, 0, 0, G, 
{-0, 0,0, 0,:0, 0. 0,:-0, 0,0, 0,.0,-60, 0,.0, GF, 
{ 0, 0,.0, 0, -0,-0,.0,-0; 0,0, 0, 0,6, 0, 0, 0, 
{ 0, 6, 0,32,32, 0; 0, 0, 0, 0, 0, 6, 0, 0, 4, 63, 
{ 6, 0,:0,32,52, 0, 0,-0, 0,0, 8, 0, 0, 0, 0, OG, 
{ 0, 0, 0, 0,0; 0, 0,-0; 0,0, 0, 0,0, 0, 6, OF, 
{ 0,32,32, 0, 0, 0, 0, 0, 0,0, 0, 0, 0, 0, 0, OF, 
£050, 0, 0, 8,0, 0,:6, 8, :0,-0, 2, ‘8, 0, &,. 8t, 
(0, 0, 0, 0,0; 0, 0; 0, 0, 0, 0, 0, 0, 0,0, OF, 
(0, 0,0, 0, 0, 0, 0, 0,32,32, 0, 0, 0, 0, 0, 03, 
£0, 0,0, 0,.0, 0, 0, 0,32,-0, 0, 0, 0, 0, 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0, 0,32, 0, 0, 0, O, 0, 0, OF, 
£°0,-0, 0, 0,0, 0,-0, 0,32, 0, 0, 0,0; 0,0, OF 
7 


As you can probably tell from the names floorfites and ceilinglites, the first of 
these is a map of light intensities for the oor and the second is a map of light 
intensities for the ceiling. The floortites// array will also contain light intensities 
for the walls, since well be using block-aligned walls that cannot coexist in the 
same maze squares with visible Hoor tiles, so by combining the wall and Hoor 
maps we ll avoid some potential redundancy. Pixels in wall, floor, and ceiling tiles 





GARDENS OF IMAGINATION 


will have the floerfites// value for the current maze square added to the intensity 
value of all other light sources falling on them (with a top intensity value of 32, 
as before), 

In my continuing attempt to set a new world record for parameter passing, the 
prototype for our lightmapped version of the araw mazef) function looks like this: 
void draw_maze(map_type map,map_type floor,map_type ceiling, 

map_type floorlites,map_type ceilinglites, 
char far *screen,int xview,int yview, 

float viewing_angle,int viewer_height, 

int. ambient_lLevel,unsigned char far *textmaps, 
unsigned charCMAXLIGHT+1JCPALETTESIZEI, 
unsigned char *Litelevel); 


This prototype will be placed in the file LITEMAPH. The function itself is in 
the hle LITEMAP-CPP. 

This time, we'll use the lightsourced version of the draw_maze() function that 
we developed a few pages ago as a template for the new function, However, only 
three lines in the entire function need to be changed, the three lines that calculate 
the light level before a lightsourced pixel is added to the wall, Hoor, and ceiling, 
respectively. In the earlier function, this line looked up a color value for the 
current distance in the /ftelewel// array and added the ambient term to it to find 
the light level of the pixel. The only additional step we need to take is to add the 
floorlites[] value for the maze square to the intensity tor Hoor and wall pixels: 
int Level=litelevelldistance]+ambient_lLevel+ 

floorLites(xmaze lL ymaze; 
And we can add the ceiling/rtes// value for the maze square to the intensity for 
ceiling pixels: 
int lLevel=LitelevelLdistancel+ambient_lLevel+ 
ceilinglitesLxmazellymaze; 


if (level>MAXLIGHT) Levwel=MAXLIGHT; 
screenLoffsetJ=LitesourcelL level JLtextmapsLtileptri; 


The Lightmapped draw_maze() Function 


Although it seems almost redundant to include it, the text of the lightmapped 
version of the draw _maze() function appears in Listing 11-4. 





Listing 11-4 The lightmapped draw_maze function 


// LITEMAP.CPP 
if 





if 
if 
if 
if 
ff 
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Function to draw texture-mapped walls, floors and 
ceilings using ray casting. 

Written by Christopher Lampton for 

GARDENS OF IMAGINATION (Waite Group Press) 


finclude <stdio.h> 
finclude <math.h> 
fFinclude "Litemap.h" 
Ainclude "pex.h" 


// Constant definitions: 

const WALL HEIGHT=64; /* Height of wall in pixels 
const VIEWER_DISTANCE=192; // Viewer distance from sereen 
const VIEWPORT_LEFT=0; ‘/ Dimensions of viewport 


const VIEWPORT_RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT_BOT-VIEWPORT_TOP; 
const VIEWPORT_CENTER=VIEWPORT_TOP+VIEWPORT_HEIGHT/2; 
const GRIDSIZE=16; 

const MAXDISTANCE=64*GRIDSIZE; 


void draw_maze(map_type map,map_type Tloor,map_type ceiling, 


if 
if 
ff 
if 


map_type floorlites,map_type ceilinglites, 

char far *sereen,int xview,int yview, 

float viewing_angle,int viewer_height, 

int ambient_level,unsigned char far * textmaps, 
unsigned char LitesourceLMAXLIGHT+1JICPALETTESIZEI, 
unsigned char *“Litelevel) 


Draws a ray-cast image in the viewport of the maze represented 

in array MAPLJ, as seen from position XVIEW, YVIEW by a | 
viewer Looking at angle VIEWING_ANGLE where angle 0 is due 
north. (Angles are measured in radians.) 


‘/ Variable declarations: 

int sy,offset; f/f Pixel y position and offset 

float xd,yd; ff Distance to next wall in x and ¥ 
int grid_x,grid_y; // Coordinates of x and y grid lines 
float xcross_x,xcross y; // Ray intersection coordinates 
float ycross_x,ycross_y; 

unsigned int xdist,ydist; // Distance to x and y grid Lines 


int xmare,ymaze; // Map location of ray collision 
int distance; // Distance to wall along ray 
int tmcolumn; // Column in texture map 


float yratio; 


/f Loop through all columns of pixels in viewport: 
for Cint columm=VIEWPORT_LEFT; columm<VIEWPORT_RIGHT; column++) f 


‘f Calculate horizontal angle of ray relative to 
conrad GO MEAS Daler 
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comtiiturd ran preon: page 
// center ray: 
float column_angle=atan(( float) (column-140) 
/ VIEWER_DISTANCE):; 


‘f Calculate angle of ray relative to maze coordinates 
float radians=viewing_angle+column_angle; 


‘/ Rotate endpoint of ray to viewing angle: 
int x2 = -1024 * (sin(radians)); 
int y2 = 1024 * (cos(radians}); 


‘/ Translate relative to viewer's position: 
Ne+=xVieW; 
yet=yview; 


ff Initialize ray at viewer's position: 
float x=xview; 
float y=yview; 


ff Find difference in x,y¥ coordinates along ray: 
int xdiff=x2-xview; 
int yditft=y2-yview; 


{/ Cheat to avoid divide-by-zero error: 
if (xdiff==0) xdiff=1; 


(/ Get slope of ray: 
float slope = (floatiydiff/xdiff; 


‘/ Cheat (again) to avoid divide-by-zero error: 
if (slope==0.0) slope=.0001; 


‘/ Cast ray from grid Line to grid Line: 
for (;;) f 


‘i If ray direction positive in x, get next x grid Line: 
if (xdiff>0) grid_x=(Cintix & OxffcO)+64; 


ff If ray direction negative in x, get last x grid line: 
else grid_x=(Cint)x & OxffcO) - 1; 


‘/ If ray direction positive in y, get next y grid line: 
if Cydiff>0) grid_y=(Cint)y & OxffcO) +64; 


if If ray direction negative in ¥y, get last y grid Line: 
else grid_y=(Cint)y & Oxffcl) - 1; 


‘/ Get x,¥ coordinates where ray crosses x grid Line: 
xCross x=grid_x; 


xeross_y=ytslope*(grid_x-x); 


// Get x,y coordinates where ray crosses y grid Line: 
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yeross x=x4+(qrid_y-y)/sLlope; 
yeross_y=grid_y; 


ff Get distance to x grid Line: 
xO=KCross_KX“x; 

yd=xcross_y-y; 
ydist=sort(xd*xd+yd* yd) > 


ff Get distance to y grid Line 
xd=ycross x-x; 

yo=ycross_y"¥; 
ydist=sqrt(xd*xd+yd*yd) ; 


ff If « grid line is closer... 
if (xdist<ydist) f 


‘/ Calculate maze grid coordinates of square: 
xmaze=xcross_x/64; 
ymaze=xcross_y¥/64; 


/? Set x and y to point of ray intersection: 
K=XCrOSS x; 
y=xcross_y; 


‘/ Find relevant column of texture map 
tmcolumn = Cintdy & Ox3f; 


ff Is there a maze cube here? If so, stop looping: 
if (mapCxmazelJCymaze]) break; 

} 

else { // If y grid Line is closer: 


‘/ Calculate maze grid coordinates of square: 
xmaze=ycross_x/64; 
ymaze=ycross_y/64; 


ff Set x and y to point of ray intersection: 
M=ycross_™; 
Y=YCPOSS_¥; 


‘f/f Find relevant column of texture map: 
tmcolumn = (int)= & Ox3f; 


ff Is there a maze cube here? If so, stop looping: 
if (mapCxmazellymazel]) break; 


} 


ff Get distance from viewer to intersection point: 
xd=x-xview; 
y¥d=y-yview; 


Lightsourcing 
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distance=(Long)sqrt(xd*xd+yd*yd)*cos(column_angle) > 
if (distance==0) distance=1; 


/f Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 


/f Calculate bottom of wall on screen: 
int bot = VIEWER_DISTANCE * viewer_height 
f distance + VIEWPORT CENTER; 


/f Calculate top of wall on screen: 
int top = bot - height; 


// Initialize temporary offset into texture map: 
int t=tmcolumn; 


ff If top of current vertical Line 15 outside of 

// viewport, clip it: 

int dheight=height; 

int iheight=IMAGE HEIGHT; 

¥ratio=(float}WALL HEIGHT/‘height; 

if (top < VIEWPORT_TOP) 
dheight-=(VIEWPORT_TOP —- top); 
t+=Cint) CCVIEWPORT_TOP-top)}*yratio)*320; 
jheight -= ((VIEWPORT_TOP-top)*yratio); 
top=VIEWPORT_TOP; 

} 

if (bot > VIEWPORT_BOT) { 
dheight -= (bot - VIEWPORT BOT); 
jheight -= (bot - VIEWPORT_BOT)*yratio; 
bot=VIEWPORT_BOT; 

: 


ff Point to video memory offset for top of Line: 
offset = top * 320 + column; 


ff Initialize vertical error term for texture map: 
Int tyerror=64; 


‘f Which graphics tile are we using? 
int tile=mapCxmazelJlymazeJ-1; 


/f Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE _HEIGHT+(tilex5) 
*IMAGE_WIDTH+t; 


{f/f Loop through the pixels in the current vertical 
‘/ Line, advancing OFFSET to the next row of pixels 
‘/ after each pixel is drawn. 

for (int h=0; h<theight; het) ft 


// Are we ready to draw a pixel? 
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while (tyerror>=IMAGE_HEIGHT) ¢ 


// If so, draw it: 

int lLevel=LitelevelCdistancel+ambient_lLevel+ 
floorliteslxmaze lL ymaze]; 

if (level>MAXLIGHT) Level=MAXLIGHT; 

screenloffset J=Litesourcellevel Jl textmapsltileptrJd; 


ff Reset error term: 
tyerror-=IMAGE HEIGHT; 


// And advance OFFSET to next screen Line: 
offset+=320; 
} 


// Incremental division: 
tyerror+=height; 


‘/ Advance TILEPTR to next Line of bitmap: 
tileptr+=320; 
} 


// Step through floor pixels: 
for Cint row=bot+1; row<=VIEWPORT_BOT; row++) f 


// Get ratio of viewer's height to pixel height: 
float ratio=(floativiewer_height/(row-100); 


‘/ Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


‘/ Rotate distance to ray angle: 
int x = — distance * (sin(radians)); 
int y = distance * (cos(radians}); 


ff Translate relative to viewer coordinates: 
M+=xV10EW; 
¥r=yview; 


ff Get maze square intersected by ray: 
int xmaze = =x / 64; 
int ymaze = y / 64; 


/f Find relevant column of texture map: 
int t = (Cintiy & Ox3f) * 320 + (Cintix & Ox3f); 


// Which graphics tile are we using? 
int tile=floorLxmazelLlymazel; 


// Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tilez5) 
*=TMAGE WIDTH+t; 


CORT OF RET Penge 
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} 


// Calculate video offset of floor pixel: 
oftset=row*320+column; 


f/f Draw pixel: 

int level=litelevellCdistancel+ambient_lLevel+ 
floorlitesCxmazellymazed; 

if (level>MAXLIGHT) lLevel=MAXLIGHT; 

screenLoffsetl=Litesourcellevel JltextmapsCtileptrii; 


// Step through ceiling pixels: 
for (row=top-1; row>=VIEWPORT_TOP; --row) f 





// Get ratio of viewer's height to pixel height: 
float ratio=(float) (WALL _HEIGHT-viewer_height)/(100-row): 


ff Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


// Rotate distance to ray angle: 
int x = = distance * (sin(radians)); 
int y = distance * (cos(radians)); 


f/f Translate relative to viewer coordinates: 
X+=KVIEWS 
¥t=yVIeH; 


/f Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 


ff Find relevant column of texture map: 
int t = (Cintdy & Ox3f) * 320 + (Cint)x & Ox3f); 


/f Which graphics tile are we using? 
int tile=ceilingLxmazellLymazel; 


// Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* 1MAGE_HEIGHT+(tilex5) 
*TMAGE_WIBTH+t; 


// Calculate video offset of floor pixel: 
of fset=row*320+column; 


// Draw pixel: 

int Level=LitelevelCdistancel+ambient_level+ 
ceilinglitesCxmazel]lymazel; 

if €level>MAXLIGHT) Level=MAZLIGHT; 

screenLoffsetJ=LitesourcellevelJ[textmapsCtileptrJ; 
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The MAPDEMO.CPP Program 


The text of MAPDEMO.CPP, a short demonstration program that calls the 
lightmapped version of the dnaw_maze() function to draw a lightmapped view of 
a maze, appears in Listing 11-5. 





Listing 11-5 The MAPDEMO.CPP program 


// MAPDEMO.CPP 


// Calls ray-casting function to draw light-mapped 
f/f wiew of maze. 


f/f Written by Christopher Lampton for 
ff Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 
finclude «dos.h> 
finclude <conio.h> 
Hinclude <stdlib.h> 
Hinclude <math.h> 
Finclude “secreen.h" 
Hinclude “pex.h" 
fFinclude “Litemap.h" 


const GRIDSIZE=16; 

const MAXDISTANCE=64*GRIDSIZE: 
const NUM_IMAGES=15; 

const float MULTIPLIER=3; 


pex_Struct textmaps; 

FILE *handle; 

unsigned char Litetable[MAXLIGHT+1JCPALETTESIZE]; 
unsigned char *lLitelevel; 


‘f/f Map of wall textures: 
map_type walls=f 


{ 5, 5,5, 5,5, 5, iis Sp Sy Ss..5,-5; $).9,5).SF, 
{ 5, 5, 0, 3, 0, 0, 0, €, 0,.0, 0, 0, 0, 0, 0, 53, 
{ 3,-0, 0, 0)..0, G,.0; 05-3)-0,:0;5-0, 0,0, O, 53, 
{ 3, 0,0, 0,0, 0,20, 0, 0,6, 0,/0, @,:0,.0,. 53, 
{ 5, 0, O, O, 0, 0, 0, 0, 0, 0, 3, 4, 0, 0, 0, 533, 
(12, 0, O, 0, 0, 0, D0, 0, 0, 0.11,11, 0,0, O, 5}, 
{11,..0, 8,.0, 0, 0,-0, 0, 0,0, 0,11, 10,.0, 0,53, 
{i1, O, O, O, 0, 0, O, 0, 0, 0, 0, 0,130, 0, 0, 51, 
C11, 5, 5, 0, 0, 0,0, 0, 0; 0,.0,41,10, Oo, 0, 5:3, 
(11, 0, 0, 0, 0, 0, 0, 0, 0, 0,11,11, 0,.0, 0, 51, 
(ie,.:39 3) OG, 0,5, Tec, 1,..0,.0, 8,..0)0,. 53, 
t3, 0,0, 0,:°6, 0,0, 1,0, %,0,-0; 8:0; 0, 5I,; 


COnttied oo net har 
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ff Map of floor textures: 
map_type flor=t 
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ff Map of ceiling textures: 

map_type ceiling=i 

(13, 13,135,135, 13, 15,135,135; 13, 15; 1a, 13, 13,135, 135; 1335 
75, 15,713,135, 135,15, lop lag top lop bop log lop lop lop bol 
(73, 135;,73,15,13,13;, 135,15, lo, oe to, 13, 1355 135,15, 14, 
£13,135,15,13,15, 13,15, 15¢1a;7 la, 14, 13,155 15,15; 15) 
£13, 13,13,15,13,135, 135,145, 15, lo; (oy lay lay lo, lop los 
{73,15,13,15,13,135,135, 15,15, 13,12; 15,15, 15, 13,1 3s 
(13,135,135, 6,-6, 15,135,759; 15, 14,14, 14, 15, 15,15, 13); 
{135,135,14,. 6, (6,135,135, 13,135,135; 13, 15,15,15,15; 13h 
(73, 15,173,135, 13,12, lo, lap loe lp os ley lay lop lo ll 
TS Oy Bae Vg Le boty Late oe Lot Doe Vo Loe Doty Patel oe Pode 
(13,13, 13,135,135, 135,13,15,15, 13,14, 13;13,15,15,13),; 
{13,15,13; 13, 13,13) 13,15, 15, 135; 15, 15,135,135, 13, 15s 5 
Lt Sp lay los lop lop loy lop lop lop os lop log lop lop Pol, 
(145,13,15, 135,145,135, 15,14, 14,153,145, 13,135, 13,13,14F, 
£15, 15,13,13,13, 13,135,135 ,15),135,13, 13,135, 135,15; 135), 
£13,13,135,13,135,13,15,13) 15,15; 13,15,15,15,15,135) 
}; 


// Map of floor Lighting: 
map type floorlites= 
{ BO. oO, 0; 85:0, 
t 6, 0, @,. 0,0, @,..B, 
{ 0, O, 0, 0, O, O, 0, 
{32, 0, 0, 0, 0, 0, O, | 
{ 0, 0, 0, 0,.0, @,.0, 
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{ 0, 0, 0, 0, 0, O, 0, 0, 0, O, 0, 0, 0, 0, 0, OF, 
{-0, 0, 0,16, 16,0, 0, 0,-0, 0, 0,-0, 0,-0, 0,-0F, 
{ 0, 0, 0,16,16,.0, 0, 0,0, 6, 0, 0, 0, 0, 0, OF, 
{ 0,32, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
{32,3¢,3¢, 0, 0, 0, 0, 0, 0, 0; 0, 0, 0, 0, 0, 0}, 
{ 6,22, 0,0, 0,-0, 0, 0, 0, 0, 0, 0, 0,0, G, 0}, 
{ O, 0, 0, O, O, Oo, 0, O, O, Oo, O, 0, Oo, 0, O, OF, 
SS 8 85:0, 05: OF 0.32 32,32. 05-0, 0,:-0;.0; OF; 
jb, 6yo8> Ob, 0, 32,352,352, 0, 0, 0,90; 6,0), 
{ 0, 0, 0, 0, 0, 0, 0,32,32,32, 0, 0, 0, 0, OU, OF, 
{ 2. 0, 0,0, 0, 0,0, 0,32, U;,. 2,0, U, U, U, OF 
hy 

ff Map of ceiling Lighting: 

map_type ceilinglites=f 

65° 0) 0,0, 0, 0,8, G, 0, 6,-0,.0, 0,-0, §,.-0F, 
10, o §,.0,-0;,. 0,0, &,--0,. 6,. 4, 0,-0, 0,6, 
{ 0,.0, 0,.0, 0, 0, 0, G,. 0, 0, G,:0, 0, 0, .0, OF, 
{/6,:0, 0, 0, 6, 0,:0, 0,0, 0, G, 0, G, 0,'°0,°-03, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, OF, 
1 0, 8, O.. 0, 0,0, 0, 0,0, 0,.0,..05 Ud, &, UF, 
{0,.0, 0,32,32, 0,0, 0, 0, 0, 0,0, 0, 0, 0, 03, 
i O.--0, 0,354,352; 05-0; 0,0, 8, 6,8, 02.0, @,-6, 
1-4, 0,0, 05.0, G,..0,.:0,.4,.8, bo. 0 OF, 
{ 0,32,42, 0,.0, 0, 0, G,-0, 0, 0, 0, 0, 0, 0, OF, 
4% 9, 0, 0, 0, 0, 6,0, 0,0, 0, 0,9, 0, 0, 0,.03, 
7G, 0, 0,4, 0,. 0. G,-0, 6,0, 0 O--8 0,0, 
£ 0,0, 0, 0, 0,0, 0, 0,352,324, 0, 0, 0,-0, @,. 07, 
£0, 0, 0,0, G,.0,.0, 6,32, 0, 0, 0, 0, 0, 6, OF, 
1 Boo Eo. G.a45 8S 0, 0, Go 0.0}, 
{G, 0, 0,-0,°0, 0,.0;, 0,32, 0,0, 0, 0,.0,'6,.0) 


+} 


float viewing_angle=0; 
float intensity=MAXLIGHT; 
int viewer_height=32; 

int ambient_level=0; 

int xview=8*64+3¢ ; 

int yview=8"*64+32 ; 

int Lighttype=1; 


void mainflint argc,char*® argvlJ) 
f 
/f Read arguments from command Line if present: 
if Carge>==2) viewing_angle=atoflargv[1]); 
if Carge>=3) intensity=atoflargvl2]); 
if Carge>=4) ambient_Level=atoflargv[3]); 


// Load texture map images: 
if CloadPCX("images3.pcx",&textmaps)) exit(1): 


‘// Load Lightsourcing tables: 
1f (Chandle=fopen("Litesorc.dat","rb")})J==NULL) ¢ 


Comrie ny Pee Prange 
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contre from preeions pape 
perror("Error"): 
exit; 
} 
fread(li tetable, MAXLIGHT+1,PALETTESIZE,handle) = 
fclose( handle); 


‘/ Allocate memory for array of Light levels: 
Litelevel=new unsigned charCMAXDISTANCE]; 


/f Calculate light levels by distance: 

for Cint distance=1; distance<MAXDISTANCE; distance++) { 
Tloat ratio=(float)intensity/distance*MULTIPLIER; 
af Cratio>=1.0) ratio=1.0; 
LitelevelCdistancel=ratio*MAXLIGHT; 

F 


// Point variable at video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


// Save previous video mode: 
int oldmode=*(Cint *)MK_FP(Ox40,0x49) ; 


ff Set mode TSh: 
setmode(Qx13); 


ff Set the palette: 
setpalette(textmaps.palette): 


/f Clear the screen: 
clatscreen); 


// Draw @ ray-cast view of the maze: 

draw_maze(walls,flor,ceiling,floorlites,ceilinglites, 
screen, xview,¥View,Viewing angle,viewer_ height, 
ambient_level,textmaps. image, litetable, 
litelevel); 


// Wait for user to hit a key: 
while ('kbhit()); 


‘/ Release memory 
delete textmaps. image; 
delete Litelevel; 


‘/ Reset video mode and exit: 
setmodeColdmode) ; 


To run the program, go to the LIGHT directory and type MAPDEMO. The 
result is shown in Figure 11-11. Several portions of Hoors, walls, and ceilings 
have been illuminated, an effect that becomes more obvious in the distance, 
where the light from the players torch becomes less intense. As in the previous 
demo, you can type tn three command line arguments, representing the angle of 
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view, the intensity of the light carried by the viewer, and the ambient lighting 
level. If you type MAPDEMO 3.14 0 0 youll see the same view as above; but 
with the players light turned completely off. Now the lightmapping is the ovrly 
source of illumination, an effect that ts quite dramatic but not entirely realistic. 
In the real world, at least some light would spill over trom the illuminated areas 
into the rest of the scene. We can simulate this effect by raising the ambient level 
ever so slightly, with the instruction MAPDEMO 3.14 0 4 (see Figure 11-12). 
Or we can raise the intensity of the rorch instead, with the instruction 
MAPDEMO 3.14 4 0, as shown in Figure 11-13. Play around with different 
angles, source intensities, and ambient levels for a while and see what sort of 


effects WOU can produce. 


Tiled Lightmaps 


The limitations of block-aligned lightmaps are pretry much the same as the 
limitations of block-aligned heightmaps. Changes in light intensity can only 
occur at block boundaries and must therefore have squared off edges, an eftect 
that isn't always realistic. Just as tiled heightmaps helped us solve some of 


the problems of block-aligned heightmapping, tiled lightmaps can help us solve the 
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Figure 11-11 Lightmap tiles in a maze Figure 11-12 Lightrmap tiles glowing in 
otherwise lit by the viewer's torch the middle of a pitch-dark maze 





Figure 17-13 Lightrmap tiles in a slightly 
better illuminated maze 
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problems of block-aligned lightmapping. And tiled lightmaps are easier to use 
than tiled heightmaps, since we don't have to worry about raised pixels blocking 
our view of height changes that fall partially in their shadow. 

By now, you can probably hgure out how tiled lightmaps work without any 
prompting from me. There's a PCX file containing multiple lightmap tiles in the 
LIGHT directory under the name LITEMAPS.PCX. It consists of a nine-part 
map forming a large circular pool of light (the middle tile of which doubles as a 
fully illuminated square of light), a single tile representing a small circular pool of 
light, and a tile with a diagonal slash of light. Each pixel in the lightmaps has a 
color value in the range 0 to 33, representing the amount to be added to the 
intensity values of the corresponding screen pixels, the total value not to exceed 32. 

Well still pass the floorlites// and cerftngittes/! arrays to the draw_mazef') 
function. And — for yet another world record — we'll pass an additional 
parameter called /itemaps that points to the light tiles themselves. The new 
prototype, in the file TLMAPH, looks like this: 
void draw_maze(map_type map,map_type floor,map_type ceiling, 

map _ type floorlites,map_type ceilinglites, 
char far *screen,int xview, int yview, 

float viewing_angle,int viewer_height, 

int ambient_level,unsigned char far *textmaps, 
unsigned char far *litemaps, 

unsigned charLMAXLIGHT+1TJILPALETTESIZEI, 
unsigned char *Litelevel); 


Before we place a pixel on the display, we've been calculating a value called 
tileptr to point to the offset in the texture-map array that contains the color value 
for that pixel, Now we'll use exactly the same method that we used to calculate 


tileptr to calculate a value that we ‘ll call liteptr, which will point to the value in 
the lightmap array that represents the light Intensity of the current pixel: 


tile=floorlites(xmazellymazed; 
unsigned int Liteptr=(tile/5)*320* 1MAGE_HEIGHT+(tilex5) 
* IMAGE _WIDTH+t ; 


Then we can add this value to the intensiry value for the prxel: 


int level=Litelevel CdistanceJ+ambient_Level+ 
Litemaps(liteptrd; 


And that’s all the code that we need to add to use tiled lightmaps. 


The Tiled Lightmapping draw_maze() Function 
The complete text of the tiled lightmapping version of dnaw_maze() appears in 
Listing 11-6. 
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Listing 11-6 The tiled lightmapping draw_maze 
function 


ff LITEMAP.CPP 

fi 

‘f/f Function to draw texture-mapped walls, floors and 
ff ceilings using ray casting. 

‘f/f Written by Christopher Lampton for 

// GARDENS OF IMAGINATION (Waite Group Press). 

if 


finclude <stdio.h> 
Finclude <math.h> 
Hinclude “tlmap.h" 
finclude “pex.h" 


‘/* Constant definitions: 


const WALL HEIGHT=64; ‘/ Height of wall in pixels 
const VIEWER_DISTANCE=197; ‘/ Wiewer distance from screen 
const VIEWPORT_LEFT=0; ‘/ Dimensions of viewport 


const VIEWPORT _RIGHT=319; 

const VIEWPORT_TOP=0; 

const VIEWPORT_BOT=199; 

const VIEWPORT_HEIGHT=VIEWPORT_BOT—VIEWPORT_TOP; 
const VIEWPORT CENTER=VIEWPORT TOP+VIEWPORT_HEIGHT/?2; 
const GRIDSIZE=16; 

const MAXDISTANCE=64*GRIDSIZE; 


void draw_maze(map_type map,map_type floor,map_type ceiling, 
map_type floorlites,map_type ceilinglites, 
char far *screen,int xview,int yview, 
Tloat viewing_angle,int viewer_height, 
int ambient_level,unsigned char far *textmaps, 
unsigned char far *Litemaps, 
unsigned char LitesourceLMAXLIGHT+1 JLPALETTESIZEJ, 
unsigned char *lLitelevel) 


‘/ Draws a ray-cast image in the viewport of the maze represented 
/f in array MAPCI, as seen from position XVIEW, YVIEW by a 

f/f wiewer looking at angle VIEWING _ ANGLE where angle 0 is due 

/f north. (Angles are measured in radians.) 


‘/ Variable declarations: 
int sy,offset; ff Pixel » position and affset 
Tloat xd,yd; ff Distance to next wall in x and ¥ 


int grid_x,grid_y; // Coordinates of x and y grid Lines 
float xcross_x,xcross_y; // Ray intersection coordinates 


COPC Aan er PRCT Page 
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rete fi pi eed fr ee Ff Preto gi Pay 
float yoross_x,ycross_y; 
unsigned int xdist,ydist; // Distance to x and y grid Lines 


Int “maze, yMaze; ff Map Location of ray collision 
int distance; // Distance to wall along ray 
int tmcolumn; /f Column in texture map 


float yratio; 


// Loop through all columns of pixels in viewport: 
for Cint column=VIEWPORT_LEFT; column<VIEWPORT RIGHT: columnt+) { 


‘f Calculate horizontal angle of ray relative to 
{f/f center ray: 
float column_angle=atan( (float) (column-160) 

/ VIEWER_DISTANCE}); 


ff Calculate angle of ray relative to maze coordinates 
float radians=viewing_anglet+tcolumn_angle; 


// Rotate endpoint of ray to viewing angle: 
int x2 = -1026 * (€sintradians))> 
int y2 = 1024 * (cos(radians)); 


‘/ Translate relative to viewer's position: 
¥2+=EVIEW; 
¥et=y¥V1eW; 


ff Initialize ray at viewer's position: 
tloat x=xview; 
float y=¥view; 


ff Find difference in x,y coordinates along ray: 
int xdiff=x2-xview; 


int ydiff=y2-yview; 


// Cheat to avoid divide-by-zero error: 
if (xdiff==0) xdiff=1; 


‘/ Get slope of ray: 
float slope = (float)ydiff/xdiff; 


// Cheat (again) to avoid divide-by-zero error: 
if (slope==0.0) slope=.0001; 


‘/ Cast ray from grid line to grid Line: 
for (27) f 


ff If ray direction positive in x, get next x grid line: 
if (xdiff>0) grid_x=(Cint)x & OxffcO)+64; 


‘i If ray direction negative in x, get Last x grid Line: 
else gridx=(Cint)x & OxffcO) - 1; 


‘i If ray direction positive in y, get mext y grid Line: 
if (ydiff>0) grid_y=(Cint)y & OxffcO) +64; 


— 
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if If ray direction negative in y, get Last y grid Line: 
else grid _y=(Cintdy & OxffcO) - 1; 


/f Get x,¥ coordinates where ray crosses x grid Line: 
xCross_x=grid_x; 
xcross  y=y+slLope*(grid_x-x); 


// Get x,y coordinates where ray crosses y grid Line: 
yeross x=x+(grid_y-y)/slope; 
ycross_y=grid_y; 


ff Get distance to x grid Line: 
KO=KCross_x—“K; 

yd=xcross_y-y; 
xdist=sort(xd*xd4+yd*y¥q) ; 


/f Get distance to y grid Line: 
xd=ycross_x-x; 

yd=ycross_y-y; 
ydist=sgrt(zd*xd+yd* yd) ; 


‘f/f If x grid line is closer... 
Tf txdist<ydist) f 


// Calculate maze grid coordinates of square: 
ymaze=xcross_x/ 64; 
y¥maze=xcross_¥/64; 


ff Set x and y to point of ray intersection: 
X=MCrOSS x? 
y=xcross_y; 


ff Find relevant column of texture map: 
tmeolLumnm = Cintiy & Oxf; 


ff Is there a maze cube here? If so, stop Loopina: 
if (mapCxmazeJ0ymazel) break; 

} 

else { // If y grid Line is closer: 


‘/ Calculate maze grid coordinates of square: 
xmaze=ycross_ x/64; 
ymaze=ycross_ y/64; 


‘/ Set x and ¥ to point of ray intersection: 
x=ycross_x; 
¥=¥CPrOsSsS_Y¥; 


‘f Find relevant column of texture map: 
tmcolumn = Cintdx & Ox3f; 


// Is there a maze cube here? If so, stop Looping: 
if (maplxmazelLymazel) break; 
} COMME OF RET pape 
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continued from oremiorer page 


} 


‘/ Get distance from viewer to intersection point: 
xd=x-xview; 

¥O=y=-y¥V1eH; 
distance=(Long)sart(xd*xd+yd"yd)"*cos(column_angle); 
if (distance==0) distance=1; 


ff Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 


ff Calculate bottom of wall on screen: 
tnt bot = VIEWER_DISTANCE * viewer_height 
/ distance + VIEWPORT_CENTER; 


‘/ Calculate top of wall on screen: 
int top = bot = height; 


ff Initialize temporary offset into texture map: 
int t=tmeolumn; 


‘f If top of current vertical line is outside of 

ff wiewport, clip it: 

int dheight=height; 

int iheight=IMAGE_HEIGHT; 

yratio=(float)WALL_HEIGHT/height; 

if (top < VIEWPORT_TOP) { 
dheight-=(VIEWPORT TOP - top); 
t+=C int) (CVIEWPORT_TOP=top)*yratio)*320; 
iheight -= ({VIEWPORT_TOP-top)*yratio); 
top=VIEWPORT TOP; 

} 

if (bot > VIEWPORT_BOT) f 
dheight -= (bot - VIEWPORT_BOT); 
theight -= (bot — VIEWPORT_BOT)*yratio; 
bot=VIEWPORT_BOT; 

} 


‘f Point to video memory offset for top of Line: 
offset = top * 320 + column; 


ff Initialize vertical error term for texture map: 
int tyerror=64; 


‘/ Which graphics tile are we using? 
int tile=mapCxmazel]lLymazel-1; 


‘/ Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tilez5) 
*IMAGE_WIDTH+t; 


ff Which Light tile are we using? 
tile=floorlitesCxmazel]lCymazel; 
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ff Find offset of tile and column in bitmap: 
unsigned int Liteptr=(tile/5)*320*1MAGE_HEIGHT+(tilex5) 


“IMAGE WIDTH+T; 


ff Loop through the pixels in the current vertical 
‘/ line, advancing OFFSET to the next row of pixels 
ff after each pixel is drawn. 

for Cint h=0; h<iheight; h++) f 


} 


ff Are we ready to draw a pixel? 
while (tyerror>=[MAGE_HEIGHT) 4 


ff If so, draw it: 
int Level=Litelevelldistancel+ambient_Level+ 
LitemapsCLiteptrd; 
if (Level>MAXLIGHT) Lewel=MAXLIGHT; 
screenLoffsetJl=lLitesourcelLlevel JL textmapsltileptrid; 


‘/ Reset error term: 
tyerror-=IMAGE_ HEIGHT; 


‘/ And advance OFFSET to next screen Line: 
of fset+=320; 
} 


‘/ Incremental division: 
tyerror+=height; 


if Advance TILEPTR * LITEPTR to next Line of bitmap: 
tileptr+=320; 
Liteptr+=320; 


‘/ Step through floor pixels: 
for (int row=bot+1; row<=VIEWPORT_BOT; row++) f{ 


‘/ Get ratio of viewer's height to pixel height: 
float ratio=(float)viewer_height/(row-100): 


‘/ Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angLle); 


// Rotate distance to ray angle: 
int x = -— distance * (sin(radians)); 
int y = distance * (cos(radians)); 


i/ Translate relative to viewer coordinates: 
xt=uview; 
¥+=yV1eW; 


// Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 
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romtinmrd from preeonr papy 
‘/ Find relevant column of texture map: 
int t = (Cint)y & Ox3f) * 320 + CCint)x & Ox3f); 


‘/ Which graphics tile are we using? 
int tile=floorlxmaze ]Cymaze] ; 


‘/ Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tilexs) 
*IMAGE WIDTH+t; 


‘f Which light tile are we using? 
tile=floorliteslxmaze)]lymazed; 


‘/ Find offset of tile and column in bitmap: 
unsigned int liteptr=(tile/5)*320* IMAGE HEIGHT+(tilex5) 
*IMAGE_WIDTH+t; 


‘/ Calculate video offset of floor pixel: 
offset=row*320+column; 


if Draw pixel: 
int level=Litelevel ldistance)+ambient_Level+ 
LitemapsCliteptrd; 
if (Level>MAXLIGHT) Level=MAXLIGHT; 
screenLoffsetJ=LitesourceLlevel JCtextmapsCtileptrdd; 
} 


if Step through ceiling pixels: 
for (row=top-1; row>=VIEWPORT_TOP; =<<row) { 


‘/ Get ratio of viewer's height to pixel height: 
float ratio=(float) (WALL_HEIGHT-viewer_height)/(100-row) > 


‘f Get distance to visible pixel: 
distance=ratio*VIEWER_DISTANCE/cos(column_angle); 


‘/ Rotate distance to ray angle: 
int x = —- distance * (sin(radians)); 
int ¥ = distance * Ceostradians)); 


‘/ Translate relative to viewer coordinates: 
Xt=KVIEW; 
y+=yview; 


‘/ Get maze square intersected by ray: 
int xmaze = x / 64; 
int ymaze = y / 64; 


‘/ Find relevant column of texture map: 
int t = (Cintiy & OxSt) * 320 + (Cintix & Oxf); 


ff Which graphics tile are we using? 
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int tile=ceilingl xmazellymazel; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320* IMAGE HEIGHT+(tilex5S) 
*IMAGE_WIDTH+t; 


ff Which Light tile are we using? 
tile=ceilinglLites€xmazelLymazel; 


‘f Find offset of tile and column in bitmap: 
unsigned int Liteptr=(tile/5)*320* IMAGE _HEIGHT+(tiles5) 
=TMAGE _WIDTH+t; 


// Calculate video offset of floor pixel: 
offset=row*320+column; 


‘/ Draw pixel: 

int Level=LitelevellCdistancel+ambient_level+ 
LitemapsCliteptri; 

if Clevel>MAXLIGHT) Level=MAZLIGHT; 

screenLoffsetJ=LitesourcelLlevel JLtextmapsltileptrid; 


The TLMDEMO.CPP Program 


To demonstrate the tiled lightmapping version of the draw_maze() function, we'll 
use the simple program in Listing | 1-7, 





if 
if 
if 
if 
if 
if 
fi 


Listing 11-7 The TLMDEMO.CPP program 


TLADERO CPP 


Calls ray-casting function to draw tiled lLight-mapped 
view of maze. 


Written by Christopher Lampton for 
Gardens of Imagination (Waite Group Press) 


Finclude <stdio.h> 
finclude <dos.h> 
Rinelude <conio.h> 
Ainclude <stdlib.h> 
Hanclude <math.h> 
Finclude “sereen.h" 
Finclude "“"pex.h" 
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continned from previous perme 
Hinclude "“tlmap.h" 


canst GRIDSIZE=14; 

const MAZXDISTANCE=64*GRIDSIZE; 
const NUM_IMAGES=15; 

const float MULTIPLIER=3; 


pex_struct textmaps,litemaps; 

FILE *handle; 

unsigned char Litetablel[MAXLIGHT+1]CPALETTESIZEI;> 
unsigned char *LiteLlevel ; 


// Map of wall textures: 
map type walls={ 
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CORN Red rea i reife inigr 


i 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 
{ 0, 0, 0, 0, 0, O, 0, O, 0, 6,.0, 0, 0,0, 0. OF, 
{ 0, 0, 0, 0, 6, 0, 0, 7, GO, O, O, 0, 0, 0, Oo, oF, 
{ 0, 0, 0, 0, 0, 0, G0, 0, 0, G, 0, Gd, 0, G, &,:0F 
}; 


float viewing_angle=0; 
float intensity=MAXLIGHT; 
int viewer _height=32; 

int ambient_lLevel=0; 

int xview=8"64432; 

int yview=6*64+35¢2; 

int Lighttype=1; 


void maintint argc,char® argvL]) 
{ 


ff Read arguments from command Line if present: 
if (arge>=2) viewing_angle=atoflargvl1]); 

if Carge>=3) intensity=atotlargvlé]); 

if Carge>=4) ambient_level=atoflargvl3]); 


if Load texture map images: 
if CloadPCX("images3’.pcx" ,&textmaps)) exit); 


‘f Load Light map tiles: 
if CloadPCX("litemaps.pcx",&litemaps)) exit(1); 


‘/ Load Lightsourcing tables: 
if (Chandle=fopen("Litesorec.dat","rb")}J==NULL) f 
perror("Error’); 
exit; 
} 
fread(litetable,MAXLIGHT+1,PALETTESIZE,handle}; 
fclose(handle); 


ff Allocate memory for array of Light Levels: 
Litelevel=new unsigned charCMAXDISTANCE); 


// Calculate Light Levels by distance: 

for (int distance=1; distance<MAXDISTANCE; distance++) { 
float ratio=(float)intensity/distance*MULTIPLIER; 
if (ratio>1.0) ratio=1.0; 
LiteleyvelCdistanceJ=ratio*MAXLIGHT; 

} 


// Point variable at video memory: 
char far *screen=(char far *)MK_FP(Oxa000,0); 


// Save previous video mode; 
int oldmode=*(Cint *)MK_FP(0x40,0"49); 
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/* Set mode 13h: 
setmode(Qx13); 


ff Set the palette: 
setpalette(textmaps.palette); 


ff Clear the screen: 
cls(screen); 


‘/ Draw a fay=-cast view of the maze: 

draw_maze(walls,flor,ceiling,floorlites,ceilinglites, 
screen, xview,¥vView,Viewing_angle,viewer_height, 
ambient_lLevel,textmaps. image,litemaps.image, 
litetable,lLitelevel); 


if Wait for user to Ait a key: 
while ('kbhit€)); 


if Release memory 
delete textmaps. image; 
delete Litemaps. image; 
delete Litelevel; 


ff Reset video mode and exit: 
setmodeColdmade); 


You can use this program by going to the LIGHT directory and typing 
TLMDEMQO, The result, with a large circular pool of light visible in the 
distance, is shown tn Figure 11-14. As before, you can pass the program 
command line parameters representing the viewing angle, the intensity of the 
viewers torch, and the ambient lighting level. Look around, experiment a little, 
and see what works and what doesnt. 





Figure 11-74 A screenshot from the TLMDEMO program 
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Using Lightmaps 


Lightmapping can be used to create the illusion of bright overhead light sources 
in a dungeon, or of light spilling out of another room. Entire areas of the maze 
can be mapped to their maximum intensity, to give the impression that those 
areas are in full daylight. Animated characters, which should be drawn using the 
same lighe intensity values that have been assigned to the Hoor squares (or pixels) 
upon which they are standing, will appear lighted or shadowed depending on 
where they are standing, They'll even appear silhouetted if they are standing in a 
dimly lit area with a bright lightmap directly behind them, a very dramatic effect. 

Where lightmapping comes into its own, though, is in animation. The most 
impressive effects of all can be achieved by changing the lightmapping from 
frame to frame, which is a simple matter of writing new values into the fleoriite// 
and ¢eflinglite[] arrays. Lights in the maze can be made to blink on and off, in 
strobe light fashion, or to oscillate berween dim and bright, as though someone 
were turning a rheostat. Changing light values sequentially from square to square 
— that is, turning one square off and the next square on in sequence — can give 
the impression that the light source is moving. If an animated fireball or other 
(luminated object moves from square to square along with the changing light 
source, it will appear as though the object is casting the light. With block-aligned 
lightmaps this effect might be a little rough, with the light source seeming to 
jump from maze square to maze square, but a series of light tiles could be 
designed so that it would seem as though the lightmapping were moving only a 
few pixels per frame. 

There are plenty of ways in which an imaginative programmer or game 
designer can utilize lightmapping to create dramatic visual effects. For some 
ideas, look at Id Software's Doom and Bethesda Softworks’ The Elder Scrolls: 
Arena, two games that make creative use of what appears to be lightmapping. 
And then come up with some new ideas of your own. 
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he ray-casting engines that we've developed over the last three 
chapters do a great job of rendering still images of the interior of 
| a maze, But if still images were all that we wanted to create, we 
might as well use a ray tracer such as POVRAY, which would 
| produce even more vivid images and render a wider variety of 
shapes. The whole point of using a ray-casting engine rather than a ray tracer is 
to produce images that move! 

Before our ray-casting engine is capable of creating real time animation, 
though, well need to optimize it so that it will run a great deal faster. 
Fortunately, | have a few tricks up my sleeve that will speed up this engine to the 
point where it will be useful in an animated computer game. By the end of this 
chapter, we ll have increased the speed of the engine to the point where it will be 
chugging along at a more than satisfactory pace. 

Mind you, the optimization tricks discussed in this chapter are not all that 
exist. A clever programmer should be able to speed up the engine developed in 
this chapter even further; don't assume that the tips and tricks mentioned in this 
chapter represent the whole extent of the programmer's art. Rather, the program 
presented in this chapter should SCT YOU On YOUr Way to creating an even more 


optimized program of your own. 
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The Target Machine 


The precise way in which you optimize your program will depend on the types of 
computers you expect it to be running on. For instance, considerably greater 
optimization will be necessary if you want your program to run well on machines 
based on the (now ancient) 80286 processor than if you expect it to run only on 
Pentium machines, since even the slowest Pentium processors are many times 
faster than the fastest 286s. And, as we'll see below, there are special quirks of 
the 486 and Pentium processors that must be raken into account during 
Optimization. 

When you start to optimize, you should have a target machine in mind. This 
is the minimum computer configuration necessary to run the program at 
acceptable speed. Youll need to have this machine available for testing the 
program during the optimization process, so that youll know when you've 
reached the point in your optimization where the program runs well on that 
machine. When that point is reached, you can stop optimizing, even if more 
optimization is theoretically possible. 

What kind of machine should you choose for your target machine? The 
answer to that question depends on a lot of variables, not the least of which is the 
time frame in which you expect the program to be released. The optimal target 
machine for the spring of 1995 wont be the same as the optimal target machine 
for the fall of 1996 — or even the fall of 1995. Guessing what the optimal 
machine will be, however, is a tricky business. 

At the time this book was written, the 80286 processor had long ago ceased to 
be a viable gaming machine and had been pretty much abandoned by game 
developers as a target machine. The same process was beginning to happen with 
the 80386 as well. By the time you read this, there will probably be no real need 
to use anything slower than an 80486 as a target machine, and you may well 
want to target the Pentium or whatever chip Intel releases as the Pentium's 
successor. Just be careful mot to choose such an advanced target conhguration 
that only a few lucky users will be able to run your game. 


A Few Optimization Tricks 


Most optimization tricks can be grouped into a few categories, Well discuss those 
categories before we dive into the optimizations themselves. 


Translating into Assembly Language 


Perhaps the oldest optimization trick of all ts to rewrite high-level code — code 
written in (++, for instance — in assembly language. Because assembly language 
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allows the programmer to specify the precise machine-level instructions that will 
make up the final program, it allows clever programmers to perform 
optimizations that would not be possible in high-level code. Of course, as 
compilers have become better at performing optimizations on their own, and as 
microprocessors have been redesigned in such a way that high-level optimizations 
are more and more effective, this optimization technique has become increasingly 
less important. Bur it still can produce effective increases in execution speed 
when used on time-critical code. In a moment, I'll discuss ways of identifying 
which portions of a program are ume critical. 

The Borland C++ compiler, like most state-of-the-art C/C++ compilers, lets us 
write certain portions of a program in assembly language and others in high-level 
code, so tt isn't necessary to translate an entire program into assembly language. 
This is for the best, since translating a nontrivial program into assembly language 
is a major, and extremely time-consuming, task. In this chapter, we'll concentrate 
on translating three relatively small sections of our ray-casting engine into 
assembly language. 

Incidentally, just because I'm translating portions of this ray-casting engine 
into assembly language doesnt mean that you necessarily should include 
assembly language modules in your own game engines. Many of the 
optimizations discussed in this chapter dont require assembly language in order 
ro produce beneficial results. If you aren't yet comfortable with assembler 
programming, write your first games in straight C++ or whatever high-level 
language yOu tere] comfortable using. Then, ONCE you ve mastered (or at least 
gotten pretty good at) high-level game programming, consider getting a good 
book on 80x86 assembly language. such as Robert Latores Assembly Language 
Primer from The Waite Group, and translating selected portions of your C++ 
code into assembler as a learning exercise. Bur dont do this until you feel ready. 


Unrolling the Loop 


Loops are one of the most important techniques in the programmers bag of 
tricks, By instructing the computer to execute a block of code a fixed number of 
times, or until some event occurs, a lot of power can be packed into a relatively 
small number of programming lines. And by changing the value of the variables 
referenced within the loop, the same block of code can perform a different task 
on each Iteration. 

But there's a drawback to loops, especially when the code of which the loop Is 
part needs to be highly optimized in order to perform acceptably. The 
instructions that cause the computer to repeat a block of code take time to 
execute. If the block of code in the loop is particularly small, these instructions 
may well take more time than the instructions in the loop itself. And if the loop 
will be executing many times a second, this extra time may be noticeable, 
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What can be done about this? In an extreme case — and we'll be looking at a 
couple of these extreme cases in a moment — we can eliminate the loop 
altogether. Since a loop is nothing more than a set of instructions that are 
executed repeatedly, we can write those instructions over and over again the 
number of times that they would normally be repeated. For instance, if the loop 
were to iterate ten times, we could replace the loop with a set of instructions 
repeated ten times over, This eliminates the “bookkeeping” instructions required 
by the loop, such as comparing values of variables against the loop’s limit values. 
All chat will be lett is the code that does the rea! work, such as placing pixels on 
the display. 

Perhaps your first response is that such an wnrodled loop would take up a lot of 
space in the program, But that’s nor necessarily so. If we write the loop code in 
assembly language, the size of the code within the loop can be made quite small 
and the resulting unrolled loop will often be no more than a few kilobytes in 
length — small in comparison to the hundreds of kilobytes that the completed 
program and its data will take up. You might also think that an unrolled loop 
would take a lot of typing to create, but the use of macro instructions (not to 
mention the cut-and-paste capabilities of the Borland editor) can reduce the 
typing considerably. More about that in a moment. 

Theres one more thing that you should know before you unroll a few loops of 
your own. On the 80486 microprocessor, loop unrolling might not produce the 
speed gains that would normally be expected. That's because the 486 has a 4- 
kilobyte internal memory cache, where instructions are stored after being 
executed so that they can be executed more quickly the second time around. This 
allows short loops — that is, those under 4 kilobytes in length — to execute 
quite rapidly on the 486. Thats not to say that further speed-ups cant be 
achieved by unrolling a loop or two. But if unrolling the loop makes it longer 
than 4 kilobytes, it will no longer be able to fir into the cache; and the extra time 
that the 486 spends loading the tnstructions back into the cache on each iteration 
of the loop will more than cancel our the gains. 

Fortunately, its not necessary to unroll a loop completely in order to optimize 
it. Unrolling it perhaps eight times, then placing those eight iterations in a loop, 
will give you almost 90 percent of the speed-up of a complete unrolling. For 
instance, a loop that executes 80 times can be unrolled eight times, then placed 
ina loop that executes ten times, We'll look ar such a partially unrolled loop in a 
Moment. 


Table Look-Ups 


Mathematical calculations, of which our ray-casting code has more than a few, 
can be quite time consuming to perform, One way to speed up the performance 
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of just about any piece of computation-intensive code is to avoid performing 
those computations while the code is running. Instead, perform them tn advance 
— and place the results in an array of values from which they can be retrieved 
later, when they re needed. 

This is especially useful in speeding up trigonometric calculations, such as 
sines and cosines. Most programs that feature three-dimensional graphic ettects 
only need to take the sines and cosines of a relatively limited number of angles. 
For instance, if a program only allows rays or objects (the viewer included) to be 
rotated in l-degree increments, then only 360 diferent sines and 360 different 
cosines will be needed. These can be calculated in advance and stored in 360- 
element arrays. Larer, when the sine or cosine of a given angle is required, the 
angle can be used as an index into the appropriate array and the sine or cosine 
extracted with minimum strain on the CPU, 

These tables can be calculated either during program initialization (if the task 
isnt foe time consuming) or at compile time. (If calculated at compile time, the 
tables can either be placed in program modules and compiled along with the rest 
of the program, or placed in binary data files, from which they can be loaded 
during program initialization.) 

We'll take a closer look at the precalculation of trigonometric tables in a 
moment. First, lets take a look at the type of arithmetic thar well be using in 
these tables, 


Fixed Point Arithmetic 

Until now, whenever we ve needed to solve some heavy mathematical problems in 
the program weve been developing, weve turned to Hoating point math to do 
the job. A C/C++ compiler uses floating point math when performing standard 
arithmetic operations, such as addition, subtraction, multiplication, or division, 
on pairs of numbers in which at least one number is declared as a float, a double, 
or a Jong double. Floating point is also used by library functions such as sqrt(), 
sin(}, and cas(), Although floating point is easy to use (because it’s supported 
automatically by most compilers), it isnt always the fastest way to get the desired 
mathematical results. 

When sat floating point the fastest way to get results? That's a complicated 
question, On any machine that doesnt have a built-in Hoating point unit, or fpr, 
Hoating point arithmetic can be slower than Washington, D.C. trathe at rush 
hour. However, the majority of recent computers — including those with 
80486D% and Pentium processors — come with Hoating point units as standard 
equipment. And even those machines that are not invariably equipped with fou’, 
such as those based on the 80286, 80386, and 80486SX processors, often have 
an optional unit installed in a special socket on the motherboard. 
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Even those machines with fpus installed can become somewhat sluggish when 
too much floating point math is used — with one exception: machines based on 
Pentium processors. The Pentium has a built-in fpu that reportedly works at 
lightning speed, On a Pentium, floating point may well be the best way to go 
when complex mathematical operations are required in a program. 

At the time this book was written, Pentium processors still represented a 
minor portion of the PC market. Before long, though, the Pentium may be the 
domimant processor on the computing scene. Until that happens, it's best for 
programmers of high-speed animated games to avoid floating point math 
wherever possible. 

Whats the alternative to floating point math? Fixed pointe math, of course. 
Fixed point mathematics is a surprisingly simple method for performing complex 
mathematical operations — in particular, those that involve fractions — using 
the integer registers of an [BM-compatible CPU. The 32-bit registers and 
instructions set of the 386 and 486 microprocessors are especially amenable to 
hxed point operations. 

I'll have more to say about fixed point arithmetic in a moment. 


Where to Optimize? 

Just as important as knowing Sow to optimize program code is knowing where to 
optimize the code. Theres no point in translating an entire game program into 
assembly language — a task that may take longer than writing the high-level 
version of the code in the first place. (Assembly language is also more diffeult to 
debug and maintain than high-level code, so you'll want to use it only in the 
most crucial places.) Not every loop needs to be unrolled; in fact, only a few need 
to be. There are even places in the most optimized of game programs where it's 
perfectly acceptable to use floating point math, even if the resulting program is 
targeted for a slow processor. 

Burt any program that makes use of high-speed animation has a few time- 
critical junctures that would profit from highly optimized code. The question is, 
how do you know where those time-critical junctures are? 

The answer ts: Look for the innermost loops in the animation code. 

If youre at all Huent in writing computer code, youre familiar with the 
concept of nested loops. Almost every nontrivial computer program contains a 
few of them: loops that are located inside other loops and that are executed 
several times for every time that the outer loop is executed. Most programs even 
contain loops that are nested inside loops that are nested inside loops. 
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As a rule of thumb, we can say that the more deeply nested a loop is inside 
other loops, the more important it is for that loop to be optimized, Why? 
Because inner loops are executed more times than outer loops. If a for() loop 
designed to execute 100 times is located inside another for() loop that also 
executes 100 times, which is in turn located inside yet another for() loop that 
executes 100 times, the innermost for() loop will execute 1 million times every 
time the outer loop executes 100 times. Thats a lot of iterations! Optimizations 
in the innermost loop will pay you back many times over compared to 
optimizations in the outer loop. In fact, the outermost loop may not need to be 
optimized at all, unless it contains some unusually sluggish code. 

How do you locate the innermost loops in your program? In many cases, they 
will be obvious. In our ray-casting engine, for instance, the innermost loops are 
the ones that draw the pixels in walls, the pixels in the Hoor, and the pixels in the 
ceiling. Simply by optimizing these loops, we can speed up the execution of the 
engine a thousandfold. Further optimizations will produce even more beneficial 
results, but optimizing these three inner loops will produce code that ts fast 
enough for many animation purposes. 

The profiler is a helpful tool in determining where a program most needs to be 
optimized. Proflers are programs that analyze computer code in order to 
determine which subprograms and even individual lines of code are being 
executed Mast often, By following the sliggestions of id good profiler and 
optimizing only those pieces of code that the CPU spends most of its time 
executing, you can save a lot of time that might otherwise be spent optimizing 
non-time-critical portions of a program. A good profiler will help you place your 
programming resources where they really count. 

The Borland C++ compiler comes with a profiler known as Turbo Profiler, or 
TPROF for short. Before you purchase a more powerful profiler, give this one a 
whirl. My own experience is that the Borland profiler is a powerful tool, but one 
that sometimes falls short when asked to profile very large programs or code that 
uses Hoating point arithmetic. (TPROF has some problems determining how 
much of a program's time is spent executing Hoating point instructions, which ts 
unfortunate when you consider that Hoating point can be one of the major drags 
on program execution speed.) 


More About Fixed Point Math 
Now that we know where to optimize a program, let's talk a little more about how 


tio optimize it. In particular, let's look into same of rhe details of fixed point 
math. 
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To understand how fixed point math works, think about how numbers with 
fractional values are written using the decimal numbering system. The number 
that represents one plus half of one, for instance, is written as 1.5. The number 
to the left of the decimal represents the integral (that is, whole number) portion 
of the number, while the number to the right of the decimal represents the 
fractional portion of the number, Here are a few more decimal fractions: 


152.234 
-/ JS33 
$90234.98017203322 


In each case, the numbers to the left of the decimal point represent integral 
amounts and the numbers to the right are fractional amounts. 
We can write binary numbers that have fractional values in the same way: 


L1OO0LTTOL 111100071001 
1.01 
-1110,0000001 


The rules for binary fractions are the same as for decimal fractions. The digits to 
the left of the decimal point represent integral values and the digits to the right 
are the fractions. (Strictly speaking, binary numbers don't have “decimal points” 
at all, since they arent decimal numbers. However, it’s easier to use the familiar 
term, } 

An interesting property of numbers with decimal points ts that when we 
perform certain mathematical operations on them — in particular, multiplication 
and division — the digits in the result are the same no matter where the decimal 
points in the original numbers were located. Only the position of the decimal 
changes. For instance, suppose we want to multiply the nwo decimal numbers 1.3 
and 41.7; 


13x 41.7 = 54.21 


The result is 54.21, But suppose we move the decimal point in the first number 
one position to the right and multiply instead the numbers 13 and 41.7: 


13x 41.7 = 542.1 


Interestingly, the only difference in the result is that the decimal point also moves 
one position to the right. What will happen if we also move the decimal point in 
the second number one position to the right and multiply the decimal numbers 
13 and 417? This is what will happen: 


Now the decimal point has moved Ave spaces to the right. 
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The reason for this becomes apparent if you recall what you were taught in 
elementary school about “long multiplication.” In a multiplication such as 


417 
x 13 





54.21 


the number of decimal positions to the right of the decimal point in the result is 
the sum of the decimal positions to the right of the decimal point in the 
multiplier and multiplicand (the two numbers being multiplied). This rule also 
applies to binary multiplication — and it's the secret of fxed point 
multiplication. It doesnt matter where we place the decimal point in a binary 
number as long as (a) we remember where we put it; and (b) we understand 
where it will be after we perform a mathematical operation on that number. 

For instance, if we multiply a binary number that has two digits after the 
decimal point by a binary number that has three digits after the decimal point, 
the result will have five digits after the decimal point — but the digits themselves 
will be exactly the same as if there had been no decimal point at all. This means 
that we can perform fixed point math with the same integer math instructions 
that we use on numbers without decimal points, as long as we keep track of the 
position of the decimal point after each operation and treat the numbers 
accordingly, 

Addition and subtraction are a great deal easier to perform on fixed point 
numbers, because they don't move the decimal point at all. In fact, the standard 
C/C++ and assembly language addition and subtraction instructions can be used 
with fixed point numbers. However, you must be sure that che decimal points are 
in the same positions in the numbers to be added or subtracted, even If it’s 
necessary to shift the decimal point into the proper position before adding or 
subtracting. We'll see how to perform such a shift in a moment. 

In the code that we develop in this chapter, well assume that all hxed point 
numbers are 32-bit /ong values with a decimal point right in the center, so that 
each fixed point number will have 16 digits to the left of the decimal point and 
16 digits to the right of the decimal point. We'll refer to such numbers in this 
chapter as 16:16 numbers, where the colon represents the decimal point and the 
numbers to both sides of the colon represent the number of digits on those sides, 
There's no rule that says there Aave to be that many digits on both sides of the 
decimal point. You can place the decimal point anywhere that you find useful, as 
long as you remember where it is. For instance, if you are dealing strictly with 
numbers in the range 0 to 1, you might want to use 1:31 fixed point numbers, 
with only one digit to the left of the decimal point and the remaining 31 digits to 
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the right. This will give you much greater fractional precision. For our purposes, 
however, 16 binary digits of fractional precision will be enough. 


Follow That Decimal! 


Now that you know how to construct a fixed point number, the next thing you 
need to know is how to perform arithmetic on that number, Actually, you can 
use ordinary addition, subtraction, multiplication, and division operations 
between fixed point numbers (and berween fixed poinc and regular numbers). 
But you must always be aware where the decimal point is after performing those 
operations and be prepared to move the decimal point elsewhere if necessary. 

Following the decimal point in a hxed point number is a matter of learning a 
couple of rules. As youve seen, when multiplying two numbers, fixed point or 
otherwise, the number of digits after the decimal point in the result will be the 
sum of the number of digits after the decimal point in the evo numbers being 
multiplied, When dividing two numbers, the number of digit positions after the 
decimal point in the result will be the number of digit positions in the dividend 
(the number being divided into) minus the number of digit positions in the 
divisor (the number being divided into it). 

Since well be using 16:16 hxed point numbers in this book, each of which 
will have 16 digit positions after the decimal point, we know that after 
multiplying two of these numbers there will be 32 digits after the decimal point. 
But wait a minute! The largest integer type offered in C++ (or by the 80x86 
CPU) is only 32 bits long. That means that the result of fixed point 
multiplication will leave us with only the digits to the right of the decimal point. 
The 16 digits to the left of the decimal point will simply vanish. Fortunately, if 
we write our fixed point multiplication code in 80386/486 assembly language, 
theres a trick that we can use to catch those digits and put them back where they 
belong before they're lost forever. (Of course, taking advantage of these 
instructions means that our fixed point routines will not work on 80286 or 
earlier processors, But few games developed after 1983 will run on the 286, so its 
less than imperative for us to support it. If you want your game to run on a 286, 
youll either have to avoid fixed point or write your own fixed point routines 
using 286, or C++, instructions.) 

A similar problem occurs during fixed point division. The 16 digits to the 
right of the decimal point will be shifted into oblivion during a division 
operation berween two 16:16 fixed point numbers, unless we take steps to 
preserve those digits. As you might guess, assembly language also provides us 
with a trick we can use to do this. 

Both of these tricks are made possible by left- and right-shift instructions. 
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Shifting Left and Right 

A shift instruction shifts the decimal point — and all of the digits in a 
number to the right or left by a given number of digit positions. There are nwo 
types of shift instructions: left shifts and right shifts. These operations shift the 
digits and decimal to the left and right, respectively. (The directions left and right 
as used here are relative to the standard orientation of digits in a number, with 
the most significant digits — that is, those digits that represent the largest values 
— to the left and the least significant digits to the right. 

Microcomputer shift operations only work on numbers written in the binary 
notation system, because thats the way in which the computer treats numbers on 
the CPU level. For instance, if we shifted all digits in the binary number 00100 
nwo digits to the left, ic would become the number 10000. Shifting those digits 
two positions to the right would produce the result 00001 (or just 1). See Figure 
12-1 for an illustration. 

The C/C++ right-shift operation is represented by the symbols “>>" and the 
left-shift operation is represented by the symbols “<<", The number to be shifted 
should be placed to the left of these operators and the number of digit positions 
by which the number ts to be shifted is represented by the number to the right of 
these operators. To shift the digits in the number represented by the variable a 
cwo digits to the right, you would write: 


a>> e 


Similarly, to shift the digits in 4 two digits to the left, you would write: 





Right Shift 


Figure 12-1 Left-shift and nght-shift 
operations on binary numbers. 
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a << ? 


Note that this doesnt actually change the value of the variable 2, which ts still 
set to the original unshifted value. Instead, the shifted value of @ becomes the 
value of the expression itself. To shift the digits in @ three positions to the left and 
store that value back tn a, you would write: 


a «<= 3; 


The 80x86 instruction set includes several shift instructions. The SHR and 
SHL instructions shift the digits in a CPU register or memory location by a 
specified number of digit positions to the right and left, respectively. The number 
of positions must be placed in the 8-bit CL register. (If it only needs to be shifted 
by one position, the number | may be used instead of the value in the CL 
register.) For instance, to shift the digits in the 16-bit DX register by seven 
positions to the right, you would write: 


shr dx,el 


Arithmetic Shifts 


The SHL and SHR instructions are sometimes called logical shifts, because they 
shift al! of the digits in a binary number, regardless of what those digits represent. 
The 80x86 instruction set also features a pair of arithmetic shift instructions: 
SAL and SAR. The SAL instruction is, in fact, identical to the SHL instruction. 
But the SAR instruction is slightly differene from SHR, in that it doesn’t affect 
the binary digit on the far left end of the number being shifted. Since this digit is 
sometimes used as a sign bit, to represent positive (if the digit is 0) or negative (if 
the digit is 1) numbers, the SAR instruction doesnt change the sign of the 
number. It leaves negative numbers negative and positive numbers positive. 


Double-Precision Shifts 

There are two more important shift instructions that are only available on the 
80386 and newer microprocessors. [hese are the SHLD and SHRD instructions. 
These mnemonics stand for “shift left double-precision” and “shift right double- 
precision.” [hese shift instructions can be used to treat two 32-bit CPU registers 
as a single G4-bit register and shift the digits across all 64 bits. Oddly, only one of 
the two registers (called the destination register) is changed by this operation, 
though digits from the second register (called the source register) are shifted into 
the destination register. To shift a 64-bit number in, say, the EAX and EDX 
registers, a second shift instruction must be used to shift the source register, like 
this: 


mov cl,24 
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shld edx,eax,cl 
shl eax,cl 

This shifts the 64-bit number in the EAX and EDX registers by 24 digit 
positions. We can also use a 32-bit memory location as the destination register, 


like this: 


shld Cmemory_addressJ,eax,cl 


A Fixed Point Multiplication Function 


By using these shift instructions, along with the standard 80x86 assembly 
language multiplication and division instructions, we can create a set of assembly 
language functions for multiplying and dividing fixed point numbers. (The code 
that follows is adapted from a set of fixed point routines developed by game 
programmer Kevin Gliner, who generously shared his ray-casting code with me 
for this book.) We'll make these functions callable from C++, but they can easily 
be adapted d8 MOCCCSsary for use in other programming languages. 

The fixed point function that well use most often in this chapter is the one for 
multiplication, so well develop that one first. Well declare the function as a 


PROC called _ freniel: 
_f4xmul PROC 

We'll pass two parameters to this function, representing the nwo numbers to be 
multiplied. We ll call them ARG] and ARG?: 
ARG argl:DWORD, arg2:DWORD 

As usual, we need to set up the BP register to point to the (PU stack, if we 
want to be able to read the parameters that we ve passed to the function: 


push bp 
mov 6p,sp 
We'll pur ARG1 into the 32-bit EAX resister: 


mov e@ax,LarglJ 


The actual fixed point multiplication is simple. We can use the 80x86 IMUL 
(for “integer multiplication’) to muluply EAX by ARG2: 


imul arge 


However, as noted earlier, the multiplication of a pair of 16:16 fixed point 
numbers will leave 32 digits to the right of the decimal point in the result. 
Indeed, after we execute the previous instructions, those 32 digits will be sitting 
in the EAX register. What happens to the digits to the éeft of the decimal point? 


Fortunately, the 80x86 takes care of them: They've been carefully placed in the 
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EDX register. Qur 16:16 fixed point number has now become a 32:32 fixed 
point number spanning two registers. 

Betore we pass the result of this multiplication back to C++, we'll need to 
convert it back to a 16:16 hxed point number. To fit the conventions of the C++ 
compiler for passing 32-bit results from functions, the low order 16 bits of this 
number must go in AX and the high order 16 bits in DX. Since the AX and DX 
registers are simply the low order 16 bits of the EAX and EDX registers, this job 
is already half done, because the low order 16 bits of the 16:16 number were left 
in the high order 16 bits of registers EDX by the multiplication. We must move 
these digits to the lower 16 bits of the register. One way to do this is to use 
shrd eax,edx,16 


This shifts the high 16 bits of EAX into the low 16 bits of EAX, without 
affecting EDX. Why dont we simply use an SHL or SAL instruction on EAX? 
Because wed need to load the number of bit positions to shift into the CL 
register first, which would slow down the operation of the function, Since the 
number in DX:AX will be automatically passed back to C++, all we need to do is 
restore the value in the BP register, return to the calling routine, and end the 
PROC, 

pop bp 


ret 
_fixmul ENDP 


We can call this function from C++ by using the name frvmu/(). You'll notice that 
the underscore at the beginning of the name should be omitted when calling the 
function from C++, The workings of the multiplication and shift instructions are 
shown in Figure 12-2. 

The complete text of the fixmu/() function appears in Listing 12-1. 





a Listing 12-1 The fixmul function 


_ Fixmul PROC 
ARG argl:DWORD, arg2:DWORD 
push bp ; Set up BP register. 
mov bp,sp 
mov eax,arg ; Get first argument into EAX 
imul argé ; Multiply it by second argument 
shrd eax,edx,16 ; Shift high and low bytes into DX:Ax 
pop bp 
ret 


_Tixmul ENDP 
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Figure 12-2 The contents of the registers before and after the multiplication and 
shift instructions 


A Fixed Point Division Function 

Using similar logic, we can create a hxed point division instruction that will 
divide a pair of 16:16 numbers and produce a 16:16 result. The main difference 
is that we must perform the shift before we perform the division, turning the 
16:16 dividend into a 32:32 number before we divide it by the 16:16 divisor. 
The division produces a 32-bit result, with 16:16 precision, just the way we want 
it. Well use the 80x86 IDIV instruction, which divides a 32-bir divisor into a 
64-bit dividend in the EDX and EAX registers, and leaves a 32-bit result in EAX. 
The text of the fixdiv() function is in Listing 12-2. 
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Listing 12-2 The fixdiv() function 


_fixdiv PROC 
ARG numer: DWORD,denom: DWORD 
push Dp ; Set up BP register. 


mov bp,sp 

mov e@ax, numer ; Put dividend into EAX 

mov edx,@ax ; Copy it into EDX 

sar edx,16 , Shift high 16 bits of EDX back into EA 
F 
F 
F 


shlL eax,16 - Shift Low 16 bits of EAX into high 16 bits 
idiv denom > Divide by divisor 
shld edx,eax,16 ; Get result 
pop bp 
ret 
_fixdiv ENDP 


A potentially confusing part of this code is the way in which the shift is 
performed, To convert the 16:16 number in EAX into a 32:32 number in 
EDX:EAX, the value in EAX is first copied to EDX, then an SAR instruction is 
used to put the high 16 bits of that instruction into the low 16 bits of EDX, 
where they belong. This also serves to clear any earlier values out of the high 16 
bits of EDX. (If the dividend is a positive number, this will fll the high 16 bits of 
EDX with Os. If it's a negative number, this will fill the high 16 bits with Is, 
which preserves the sign of the number and allows us to use this function with 
both negative and positive operands.) The SHL instruction then shifts the low 16 
bits of EAX into the high 16 bits, filling the low 16 bits with Os. Thus the 16:16 
number becomes a 32:32 number, After the division, the SHLD instruction gets 
the 16:16 result into the proper registers to be passed back to C++, 


Fixed Point Trigonometry 
Even when working in fixed point, well need to perform such trigonometric 
functions as sine and cosine. The Borland C++ libraries dont contain any fixed 
point trigonometric functions, but its quite easy to use the Hoating point trig 
routines in the Borland libraries to create a table of fixed point sines and cosines, 
which can then be used in our program with the table look-up technique we 
discussed earlier in this chapter. 

Well create a short program called MAKETRIG.CPP thar will generate an 
ASCII text fle which will contain the initialization statements for a pair of fixed 
poine (that is, long-integer) arrays called sin_array and cos_array, This hle will be 


called TRIG.CPP MAKETRIG and will also generate the header fle TRIG.H, 
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which will contain definitions for macros that can be used to perform 
trigonometric functions using the tables in TRIG.H. 
MAKETRIG.CPP will begin with some constant dehnitions: 
const NUMBER_OF_DEGREES = 4096; // Degrees in a circle 
const SHIFT = 16; if Fixed point shift 
const Long SHIFT_MULT = (1L<<SHIFT); // Fixed point shift as 
‘f/f oa multiplication 


The constant NUMBER_OF_DEGREES is set equal to 4096 because that's 
the number of “degrees” that we'll be using in our fixed point polar coordinate 
system. This will allow us to have a fair amount of precision in the rotation of 
rays and objects while not having to spend time interpolating fractions of 
degrees. In a moment, I'll show you one method of converting the radian-based 
sines and cosines supported by the BC++ libraries into our 4096-degree system. 

The SHIFT constant represents the number of degrees that the decimal point 
in our fixed point numbers has been shifted left relative to the decimal point in a 
standard integer (which is all the way down at the righthand end of the number). 
We can use this constant to translate standard integers into fixed point numbers. 
For instance, if we wanted to translate the value of the svt variable int_number 
into a fixed point number in the /ong variable fix_number, we would write: 


fix_number = (Long)int_number << SHIFT; 


Notice that it's necessary to cast the value of int_number to a long value before 
performing the shift. Although this conversion will occur automatically when the 
value of the expression is assigned to the /omg variable fix_number, the shift 
operation will already have destroyed the digits in iat_wiwember by shifting them 
off the end of what it thinks is a 16-bit value. The typecast tells the shift to treat 
int_number as a 32-bit value, rescuing the shifted digits. 

The use of a constant here for the SHIFT value will allow us to change more 
easily to other precisions of fixed point numbers, if that should become necessary 
or desirable, though changes will still need to be made to the assembly language 
functions that deal with fixed point numbers. 

Finally, the SHIFT_MULT constant is used to convert floating point 
numbers, which cannot be shifted, into fixed point numbers using a simple 
multiplication. For instance, the value of the feat variable float_number can be 
converted to a fixed point value in the long integer variable fix_ruwmrber like this: 


Tix_number = float_number * SHIFT_MULT; 
(Note that we cant cast flogt_number into a fong and then perform a shift on it 


because wed lose the fractional portion of its value, which is precisely what our 
fixed point math system is designed to preserve.) 
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The MAKETRIG program will be fairly short, consisting of only a single 
maint) function: 


vold maint) 
{ 


Well need a variable to keep track of radians, as we translate from radians to 
our custom degree system. Time not being of the essence here, we'll make this 
variable a double, to guarantee a high level of accuracy: 


double radians=0.0; 


We'll also need a file handle for the TRIG,H and TRIG.CPP files, We'll give 
that handle the unimaginative name fname: 


FILE *fname; 


Finally, we'll need an array of char for translating our fixed point numbers into 
ASCII] characters for output, a task thats more dificult than it mighe at first 
appear: 
char hexleQJ; 


We ll create the hle TRIG.H first: 
fname=fopen("trig.h","wt"); 


This opens the file TRIG.H as a write-only text file. Now we'll write a pair of 
macro definitions to the file: 


fprintt(fname,"fdefine COS(X) cos_tablel(X&(NUMBER_OF_DEGREES=1)]\n"); 
fprintf( fname," Adefine SIN(X) sin_tableLX&(NUMBER_OF_DEGREES-1)]\n"); 


In C and C++, a macro is a kind of constant that represents a string of characters 
and can take one or more parameters, almost like a function. These two macros 
perform the sine and cosine functions using table look-ups. Each macro takes a 
single parameter, X, which represents the angle for which we want the sine 
or cosine. The string of characters that we pass to the macro will then replace 
the character X in the macro text. In each case, the value that we give X will 
be ANDed with the NUMBER OF DEGREES minus 1. When 
NUMBER_OF_DEGREES is a power of rwo (as it always should be), this will 
give us the value of x modulo the number of degrees (that is, the remainder after 
X has been divided by the number of degrees). The resulting value is then used as 
an index into the sine or cosine table. 

(Why use macros instead of functions to perform these operations? The 
compiled version of a standard C/C++ function contains a lot of code that will 
slaw these operations down. For instance, the function will be called with the 
assembly language CALL instruction and terminated with a RET, with additional 
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code to set up the stack. A macro avoids this overhead. Alternatively, we could 
use what Is known in C++ as an taline function, which works much like a macro.) 

We also want to print our constant definitions in the TRIG.H file, so that 
they ll be accessible to our programs: 
fprintt(fname,"\nconst NUMBER_OF_DEGREES = ¢d;\n", 

NUMBER _OF DEGREES); 

forintf(fname,"const SHIFT = 4d;\n",SHIFT); 
fprintf(fname,"“const SHIFT_MULT = 1<<SHIFT;\n\n"); 


These instructions will simply duplicate in the TRIG.H hie the same constant 
definitions that we've put ar the head of MAKETRIG.CPP 

We'll be storing the trig tables in the arrays cos_table and sin_table, so we'll 
add extern definitions for these arrays to TRIG.H: 


fprintt(fname,"extern long cos_tableL#d];\n", 
NUMBER_OF_DEGREES); 

fprintf(fname,"extern Long sin_tablel%d];\n", 
NUMBER OF DEGREES); 


And that’s all that we need in TRIG.H, so well close the fle: 


fclose( fname); 


Now let's build the second le, TRIG.CPP: 
fname=Topen('trig.cpp’, wt’); 

For claritys sake, let's open TRIG-CPP with some contents identifying the 
contents of the file: 
fprintt (fname, \n/s FIX. CPPi\n"); 
forintf( fname, // Fixed point math tablesinin’); 

The rest of the fle will be nothing but the initialization statements for the rwo 
arrays. We'll start with cos_table: 


fprintt(fname,"long cos_tablelXdJ={\n ad 
NUMBER OF DEGREES); 


That will declare cos_table as an array of longs with NUMBER_OF_DEGREES 
elements. The equal sign and the left curly bracket indicate that this will be 
followed by a list of 4096 fixed point cosine values. We'll calculate those values in 
a for() loop that iterates 4096 times. First, however, we'll create an int variable 
called count to help us format the data properly: 


int count=0; 
More about the count variable in a moment. 
Now we can begin the for() loop: 
or Cint degree=0; degree<NUMBER_OF_DEGREES; degree++) { 
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The loop variable degree represents the number of degrees for which we wish to 
calculate the cosine, in our 4096-degree system. Before we can use the standard 
BC++ trigonometric functions to perform the calculation, though, we must 
convert the number of degrees into radians, For this purpose, we'll create a double 
variable called radians. To convert degrees into radians, well divide the current 
number of degrees (which well first cast to a double) by the NUMBER OF_ 
DEGREES, then multiply the result by the number of radians tn a circle, which 
is 2* PI: 

double radians = (double)i/NUMBER_OF_DEGREES*3.14159%2 ; 


Well use the standard cosf) function to calculate the cosine of mdians, then 
convert it to hxed point using SHIFT MULT and store the resulting value in the 
temporary fone variable remp_long 


Long temp_long=(long)(cos(radians)*SHIFT_MULT); 


Now we have co translate this value to ASCII co ourpur it to the hile. 
Ordinarily, we would do this using the formatting capabilities of the fprintf 
statement, but these capabilities have more than a lictle trouble with outputting 
long integers, especially negative long integers. Instead, well use the standard 
ftea() function, which converts long integers into strings of ASCII characters: 


Ltoa(temp_long,hex,14); 

This converts the value of temp_leng to a hexadecimal ASCII string and stores the 
result in the char arrav hex, which we declared earlier. Now we can use fprintf to 
output this string of characters to the file FIX.CPP, with a leading “Ox” to 
indicate that the string represents a hexadecimal number: 

fprintt(fname,"Oxis, "hex; 

So that our 40%6-element initialization statement doesnt become one long 
line with no carriage returns, we'll output a return after every eighth element. 
The variable conn will be incremented by one on each pass through the loop, so 
that we'll know when eight elements have been printed: 
count++; 

When count reaches eight, we print a carriage return, plus a four-character 
indentation at the beginning of the next line: 


if Ccount>=8) f{ 
forintt( fname," in at 


And we reset count to 0: 


count=0; 





CHAPTER TWELVE Optimization 


When all 4096 clements have been printed, we || OUEpUt a closing curly 
bracket, plus two carriage returns: 


} 
fprintf( fname, }; n\n"); 


The code for the sine table is almost identical to this, except that the 
trigonometric function has been changed: 


fprintf(fname,"long sin_tableltdJ={\n > 
NUMBER_OF_DEGREES); 
count=0; 
for (i=0; i<NUMBER_OF_DEGREES; i++) { 
radians = (double}i/NUMBER_OF_DEGREES*3.14159*2; 
Long temp_long=(long)(sin( radians) *SHIFT_MULT); 
Ltoa(temp_Long,hex,16); 
fprintt(tname,”Oxcs, “,hex); 
count++; 
if Ccount>=8) ¢ 
fprintft( fname," \n ye 
count=0; 
} 
} 
forintf(fname,"}s\n"): 


The MAKETRIG.CPP Module 

The complete text of MAKETRIG.CPP appears in Listing 12-3. The text of the 
TRIG.H fle that tt generates appears in Listing 12-4. The TRIG.CPP file is 
much too long to reprint here, but a small portion of both the sin_table[] and 
cos_table[] arrays are shown in Listing 12-5. The complete file can be found on 
the disk in the OPTIMIZE directory, along with the other program files in this 
chapter. 





Listing 12-3 The MARKETRIG.CCP program 


Binclude <stdio.h> 
include <stdlib.h> 
Finclude <math.h> 

finclude <conio.h> 
Ainclude <string.h> 


const NUMBER_OF_DEGREES = 4096; // Degrees in a circle 

const SHIFT = 16; ff Fixed point shift 

const Long SHIFT_MULT = (1L<<SHIFT); £// Fixed point shift as 
ff a multiplication 


Coan OF Fre ieee 


a: 
Yala 






i 
| 
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ccniaed fron breve page 

void maint) 

c 
double radians=0.0; 
FILE *fname; 
char hexC20]; 


ff Create file TRIG.H for constants and macros: 
fname=fopen("trig.h","wt"); 


‘f Macro definitions for trig functtens: 
forintt( fname, Adefine COS(M) cos _tableLX&(NUMBER_OF BEGREES—-1)J]\n"); 
fprintt(fname,"adefine SINCX) sin_tableLX&(NUMBER_OF_DEGREES=1)]\n'"'); 


ff Constant definitions: 

forintft( fname, \nconst NUMBER_OF DEGREES = Ad;sin", 
NUMBER_OF_DEGREES): 

fprintf(fname,"const SHIFT = 4d:\n",SHIFT); 

forintf( fname, "const SHIFT MULT = 1<<SHIFT;\nin"); 


ff External table declarations: 

fprintf(fname,"extern Long cos_tablelad);\n", 
NUMBER_OF DEGREES); 

forintf( fname, extern Long sin_tableLédj;\n", 
NUMBER OF DEGREES); 

fclose( fname); 


ff Create file TRIG.CPP for data tables: 
fname=fopen("trig.cpp’,"wt"): 
fprintft(fname,"\n//TRIG.CPPin™); 
fprintt(fname,"// Fixed point math tables\nin"}; 


ff Create cosine table: 

fprintt(fname,"long cos_tableCédJ={\n vie 
NUMBER OF DEGREES); 

int count=0; 


‘/ Loop through 4096 degrees: 
for (int i=0; i<NUMBER_OF DEGREES; i++) { 


‘/ Translate degrees into radians: 
radians = (double)i/NUMBER_OF DEGREES*3.14159*2; 


‘*/ Get cosine: 
Long temp_long=(Long)(cos(radians)*SHIFT_MULT); 


ff Convert cosine to hexadecimal ASCII: 
Ltoaltemp_long,hex,16); 


ff Print it to file: 
fprintt(fname, "Oxkts, "“,hex); 


‘/ Output carriage return if eighth entry printed: 


482) 
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count+t+; 
if Ccount>=6) f 
fprintt(fname,"\n “y: 
count=0; 
} 
} 
fprintf( fname, }e\nin'o; 


// Create sine table: 

radians=0.0; 

fprintf(fname,"long sin_tablel%dJ={\n hp 
NUMBER_OF_DEGREES); 

count=0; 


// Loop through 4096 degrees: 
for (i=0; i<NUMBER_OF DEGREES; i++) { 


// Translate degrees into radians: 
radians = (double)i/NUMBER_OF DEGREES*3.14159*2; 


ff Get cosine: 
Long temp _Long=(Long)(sin(radians)*5HIFT_MULT); 


if Convert cosine into hexadecimal ASCII: 
Ltoaltemp long,hex,16}; 


f/f Print it to file: 
forintt(fname,"Oxeés, ",hex); 


// Qutput carriage return if eighth entry printed: 
countt+; 
if Ccount>=8) ¢ 
fprintf( fname," \n te 
count=0; 
} 
} 


fprintt(fname,"};\n"); 


‘/ Close file: 
fclose( fname); 


} 





Listing 12-4 The TRIG.H file 


fdefine COS(X) cos_tablelX&(NUMBER_OF_DEGREES-1)] 
fdefine SIN(X) sin_tablel#é(NUMBER_OF_ DEGREES-1)1] 


const NUMBER_OF DEGREES = 4096; 
const SHIFT = 16; 


Cor Ae OH FACET fed e 





GARDENS OF IMAGINATION 


romiinned from prevrons pape 


const SHIFT_MAULT = T<<SHIFT; 


extern Long cos_tablel4096); 
extern Long sin_tablel40%6]; 





Listing 12-5 Portions of the TRIG.CPP module 


//TRIG.CPP 

//Fixed point math tables 

Long cos_tablel4096J]=f 
Ox10000, Oxtfff, Oxffff, Oxffff, Oxtffe, Oxffte, Oxfftd, Oxfffc, 
Oxfftb, Oxfff9, Oxfffa, Oxfffé, Oxfff4, Oxfff2, OxfffO, Oxffee, 
Oxtfec, Oxffe?, Oxffer, Oxftfe4, Oxtfel, Oxffdd, Oxffda, Oxffd7, 
Oxffd3, Oxffct, Oxtfch, Oxffc?, Oxtfes, Oxffbtf, Oxtfba, Oxffb5, 


Long sin_tablel4096J={ 
Ox0, Oxd4s, Oxc9, Oxted, Ox192, Oxifé, Ox25b, Oxzbf, 
Ox324, Ox388, Ox3ed, Ox451, Oxéb6, Oxta, Ox57f, Ox5e5, 
Ox648, Oxéac, Ox?11, Ox?75, Ox?da, Ox83e, Ox8a3, 0x907, 
Ox9é6c, Ox9d0, Oxa35, Owa99, Oxafd, Oxbé2, Oxbcd, Oxc2b, 
OxcSf, Oxcté, Oxd58, Ondbc, Oxez1, OxeB8S, Oxeea, Oxfée, 


Optimized Wall Drawing 


Now that we have some grounding in the basic principles of Optimization, let's 
start optimizing code. Well pur all of our optimization into the dnaw_maze() 
function of our ray-casting engine, because this is where our programs will be 
spending the majoriry of their time. As noted earlier, we ll rewrite three portions 
of the dnaw_maze() function in machine language, as separate assembly language 
PROCSs, These PROCS will replace the portions of the code that draw the walls, 
the Hoors, and the ceilings. The code tn these three PROCS is adapted from code 
written by Kevin Gliner for his own ray- casting engine. Any bugs or bottlenecks 
in the code were added by me in the translation. 

Well restrict the wall-drawing optimization to the loop that copies a column 
of a bitmap to the wall, stretching or shrinking it as necessary by adding or 
subtracting pixels, We'll continue performing the rest of the wallcasting in C+4, 
though well use fixed point math in doing so, as youll see in a moment. To get 
things under way, lets write a function called drouswalll } 


_drawwall PROC 


fc a = 


(8a) | 
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We'll use a slightly different method of drawing the wall in this assembly 
language function than we used earlier in our C++ ray caster. Before, we used an 
incremental division method similar to that used in Bresenhams algorithm to 
decide when a pixel is to be repeated or skipped. Now, well use a simpler method 
that wasn't feasible withour the aid of hxed point math. This method involves 
dividing the size of the wall column to be drawn into the size of the column of 
pixels to be mapped onto it to produce a value that well call the faerement. The 
increment is a value which can have a fractional portion and which is added to 
the current pixel offset into the bicmap to determine which pixel is to be drawn 
next. We'll truncate the fractional portion before indexing into the bitmap, bur 
We ‘ll retain the fractional portion when Wet add the increment to the offset. Thus 
tf the value of the increment is, say, 0.5, then the bitmap offset will be advanced 
by one pixel on every other iteration of the drawing loop, since 0.5 must be 
added to the offset ewice to move it forward by 1. If the value of the increment is 
1.5, then the pointer will be advanced by 1 pixel, then 2, then | again — and so 
forth. 

We'll also make a minor change in the way the bitmaps are stored. If you look 
at the file Walls.pcx in the OPTIMIZE directory, youll see that the tiles are now 
lying on their sides, so that each “column” of each bitmap is now a horizontal 
row, This will make it easier to move along the columns, as you'll see, And we'll 
Mow he drawing the walls from bottom co top instead of from Lop TO bottom, 
which is why the bitmaps have “fallen over’ onto their right sides rather than 
their left sides, 

The drawwall() function will accept hve parameters from the calling function. 
These are a far pointer to the address in the video display or screen butter where 
the bottommost pixel in the wall column is to be drawn (sereenpfr); a far pointer 
to the first pixel to be drawn from the bitmap (értmapprr); an integer 
representing the height in pixels of the visible wall column to be drawn (heigh#); a 
16:16 fixed point number representing the increment to be added to the pixel 
offset after each visible pixel is drawn (tacrement); and a far pointer to the 
position in the lightsourcing table at which the 256 light levels can be found for 
the wall’s light level (/itelewe!): 


ARG screenptr:DWORD,bitmapptr:DWORD, height: WORD, increment: 
DWORD,LitelLevel : DWORD 


We're going to completely unroll the main loop of this function, the loop that 
actually puts the pixels in the screen buffer. You might wonder how were going 
to know in advance how many times to unroll the loop, since the number of 
iterations will depend on the height of the visible wall column. In fact, we're 
eoing to unroll it a full 200 times, which is the maximum height thar the visible 
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wall column can have on the mode 13h display, If we need to draw fewer pixels 
— and we usually will — we'll jump into the middle of this unrolled loop, 
effectively skipping over the pixels that don’t need to be drawn. To calculate how 
many pixels we must skip, well take the Aeight value passed to us from the calling 
routine and subtract it from 200, like this: 


mov bx,height 
mov ax,2¢00 
sub ax,bx 


The number of pixels to be skipped is now in AX. We'll get back to it in a 
moment. In the meantime, we'll store important values in registers. For instance, 
we ll store increment in EICX: 
mov ecx, increment 

And we'll store screenptr, bitmapper, and ftelevel in g5:51, fs:di, and es:bx, 
respectively: 


los -s1,8creenptr 
Lfs di,bitmapptr 
Les bx,litelevel 


We need to be sure that the EBX register has nothing but Os in it. Well do this 
in the ordinary straighttorward fashion, by moving a 0 into it: 
mov ebx,0 

We ll also store a constant value of 320 — the width of the display in pixels — 
in the BP register for later use: 
mov bp,320 

Now let's calculate where to jump into the loop. Each iteration of our unrolled 


loop will be 21 bytes long, so we'll multiply the number of pixels to skip (which 
we left in AX) by 21: 
imul ax,el 

Then we'll add the starting address of the loop, which will be at address 
walloop, to this value: 


mov di,otfset walloop 
add di,ax 


The address to which we need to jump is now in DI, so we'll clear our EAX: 
xor eax,e@ax 

And we'll jump to the address in DI: 

jmp 366d 
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We'll create the loop itself as a macro, so we dont have to type it 200 times. A 
macro is dehned using the MACRO directive. We'll call this macro columnloop: 


COLUMNLOOP MACRO 


Before we can put a pixel on the display, we need to index into the bitmap to 
find the pixel color. The offset for the pixel is in EDX, but its a 16:16 fixed point 
number, which won't work properly as an offset. This can be easily fixed by using 
an SHLD instruction to move the high 16 bits of EDX, which contain the 
integral portion of the offset, into the low 16 bits of the EDI register: 


shld edi,edx,16 


The DI register (which is the lower half of ED]) now contains the offser. We can 
use fsidi to fetch the pixel color into the AL register: 


mov al,fs:CdiJ 


We want to place the lightsourced equivalent of this value onto the display. 
We've put a pointer to the lightsource table in es:bx and we can use the color 
itself, in AX, to index into the table: 


mov al,es:Lebx + eax 


We have to use the full 32-bit registers for this particular addressing mode, 
which is why we cleared both EBX and EAX earlier, to be certain there were no 
stray digits in the upper 16 bits of either. 

The pixel color ts now in AL. Since gs:si points at the screen or screen butter 
location for the next pixel to be drawn, we simply copy the value from AL to the 
address pointed to by those registers: 


mov gs:Csil,al ;mov pixel color into ScreenBuftfer 


We then subtract the increment trom the pointer inte the bitmap: 


sub edx,ecx 


And we subtract 320 (which we placed earlier in BP) from the screen pointer 
in Sl: 
sub s1,bp 


In both of these cases, we subtract rather than add because were drawing the 
screen column from the bottom to the top. 

Thats the end of the macro. Back in the dnawwall() function we repeat the 
macro 200 times like this: 


walloop: 
REPT 200 
COLUMNLOOP 
ENDM 
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That sure beats typing the contents of the loop 200 times! 
All that we need to do now Is terminate the PROC in the standard fashion: 
pop bp 
ret 

_drawwall ENDP 


The drawwallQ Function 


The complete text of the drawiwadl{) function appears in Listing 12-6. The text of 


the COLUMNLOOP macro is in Listing 12-7. 






Listing 12-6 The drawwall() function 


_drawwall PROC 
ARG 

screenptr:DWORD,bitmapptr: DWORD,height: WORD, increment: DWORB,Litelevel : DWO 
RD 

push bp 

mov bp,sp 

mov bx,height 

mov ax,20U 

sub ax,bx 

mov ecx,increment 


save EP 

Set up stack pointer 

Get height in Bx 

Calculate number of pixels to skip 
Leave result in Ax 

Get increment in ECX 


Sy ee Se Te a hy 


los $1,5creenptr ; Get screen index in GS:5I 
lfs di,bitmapptr ; Get pointer to bitmap in FS:DI 
mov ebx,0 ; Clear out EBX 


les bx,litelevel : Get Lightsource table addr. in BX 
mov dx,di ; Copy increment in Ox 

shl edx,16 ; Reverse the bytes 

imul = ax,27 ; Calculate jump address 

mov di,offset walloop ; Add start of Lloop.... 


add = di,ax - ...to offset in loop 

mov bp,320 ; Store constant in BP 

XOr  G8xX,GaXx » Clear out EAX 

jmp = dit ; Jump into unrolled Loop. 
walLloop: 

REPT 200 : Repeat macro 200 times 

COLUMNLOOP 

ENDM 

pop bp , Restore BP 

ret 


_drawwall § ENDP 
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Listing 12-7 The COLUMNLOOP macro 


COLUMNLOOP MACRO 


shld edi,edx,16 ; Move integral portion of bitmap 
>; pointer inte BI 

mov al,fs:ldiJ ; Get color of next pixel 

mow al,es: Cebx + eax] ; Get Lightsourced color 

mov gs:Csil,al ; Copy pixel color to screen column 

sub edx,ecx ; Add increment to bitmap pointer 

sub 8i1,bp ; Point to next pixel in wall column 
ENDM 


Optimized Floors and Ceilings 

The optimized Hoor and ceiling drawing routines will use a somewhat different 
algorithm than we used in our C++ ray-casting function. Instead of drawing the 
floors and ceilings column by column, starting at the tops and bottoms of walls 
and drawing to the tops and bottoms of the viewport, we'll draw the Hoors and 
ceilings in rows from left to right, checking to see if there's a wall intersecting 
each column before we draw a pixel in it. 

Why are we using this method? What advantage does it give us over the 
algorithm we used earlier? 

You'll recall that in our earlier Hoorcasting and ceilingcasting routines, it was 
necessary to rotate a ray for cvery pixel | in the Hor and ceiling dfeds, (0 hind 
which pixel within the fine coordinate system of the Mldzc grid Wels intersected by 
that ray. Burt that’s inefhcient because it requires that trigonometric functions and 
multiplications be performed for each pixel, which slows the process 
considerably. Even with our new table-derived trig functions, there are still a 
couple of multiplications involved per pixel, which | [IS a couple of multiplications 
too many. [he Hoor and ceiling drawing loops will be executed, collectively, 
nearly 64,000 times when creating a ray-cast image in a full-screen viewport. 
Every CPU cycle that we can shave off of these loops will noticeably speed up our 
code, 

Fortunately, there's a better way to do this. If we draw the floors and ceilings in 
horizontal rows, we need only rotate a ray through the leftmost and rightmost 
pixels in each row, to determine which floor pixels they strike. The rays that pass 
through the intermediate pixels in a column will all fall along a straight line 
connecting these two end pixels. All we need to do to find the floor pixels 
corresponding to these intermediate screen pixels is to determine the distance 
between the two end floor pixels, divide it by the number of intermediate pixels 
to hind the increment between each pixel, then repeatedly add that Increment to 
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the Hoor pixel position to walk our way from one side of the viewport to the 
other, 

This concept is illustrated in Figure 12-3. At the bottom is the viewer, looking 
at the video display, as seen from above. Two rays shoot out from the viewer's 
eyes, one (labeled A) passing through the leftmost pixel of a Hoor column on the 
video display, the other (labeled B) passing through the rightmost pixel of that 
same Hoor column. The floor pixel struck by A will be the leftmost Hoor pixel 
visible in that row, and the Hoor pixel struck by B will be the rightmost floor 
pixel visible in that row. The dotted line from the leftmost foor pixel to the 
rightmost represents the floor pixels that will appear in the intermediate pixels on 
that row. 

Suppose the leftmost Hoor pixel is at fine coordinates 1007,659 and the 
rightmost is at coordinates 911,980. We can hind out how long the line between 
these two Hoor pixels is — thar is, how many Hoor pixels that line will pass over 
in the x and y directions — by subtracting the second set of coordinates from the 
first. Thus we know that the line passes over 911 minus 1007, or -96, pixels in 
the x direction and 980 minus 659, or 321 pixels in the y direction. Now let's 
suppose that the viewport in which these two Hoor pixels represent the extremes 
is 200 pixels wide, The distance from the leftmost pixel to the rightmost pixel is 
therefore 199 pixels. That tells us that the distance berween two floor points 
represented by adjacent screen pixels is -96 divided by 199, or -0,4824, pixels in 
the x direction and 321 divided by 199, or 1.613, pixels in the y direction, 

This gives us a method for calculating the positions at which the rays cast 
through the intermediate pixels in that row strike the Hoor. We rotate a ray 





Figure 12-3 Calculating pixel positions 
along a line from left te right 
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through the leftmost and rightmost pixels in the row to determine which Hoor 
pixels those rays strike, then subtract the coordinates of the rightmost Hoor pixel 
from the coordinates of the leftmost Hoor prxel to get the distance berween them 
and divide that distance by the distance between the two screen pixels to get the 
single pixel increment in each direction. We then add these increments repeatedly 
to the coordinates of the leftmost Hoor pixel to derive the coordinates of the 
intermediate pixels, 

For instance, in the example above, we know that the leftmost floor pixel ts at 
coordinates 1007,659 and the single pixel increment along the line connecting 
this pixel to the rightmost pixel is -0.4824,1.613. To get the coordinates of the 
floor pixel to be drawn on the screen immediately to the right of this one, we 
merely add these increments to the coordinates of the leftmost pixel. This will tell 
us that the coordinates of the second-to-the-rightmost pixel are 
1006.5176,660.613. And the coordinates of the pixel to the left of that pixel are 
1006.0352,661.226. If we keep adding these increments to the pixel coordinates 
for all of the pixels in a single row of the viewport, we can calculate the position 
of each without any multiplications or trigonometric table look-ups — except for 
those required to rotate the ray through the leftmost and rightmost rays. 

This is the algorithm that we'll use when we translate a portion of the Hoor 
and ceiling drawing routines into assemby language. The portion of the Hoor and 
ceiling drawing routines that were going to translate is the part that draws a 
single column of pixels. We'll call the resulting function drawfloorrew() and 
drawceilrow(). We'll look at drawfloorrow() in detail, since the nwo functions are 
nearly identical. 

As before, well declare arawfloorrew() as an assembly language PROC: 


_drawfloorrow PROC 
Well be passing quite a few parameters to this function: 


Bl row — the number of the viewport row in which we'll be drawing floor pixels 


7 
TT 
7 | 


screenptr— a far pointer to the position on the video display at which the row 
begins 


(| tewxturelist — a far pointer to an array of pointers to the upper-left corners of 
the 15 texture map tiles 


floormap — a far pointer to the 1616 map of the floor 


[cll televel —a far pointer to the 256-byte segment of the lightsourcing table for 
the distance at which the rays In the current column strike the floor 





GARDENS OF IMAGINATION 


fe) bots —a far pointer to an array with an element for each column of the 
viewport containing the number of the row where the bottom of bottommost 
pixel in the wall appears in that column 


‘| xine —a fixed point number representing the increment in the x direction 
between floor pixels in the row 


= 


fell vine —a fixed point number representing the Increment in the y direction 
between floor pixels in the row 


El x¥— a fixed point number representing the x coordinate of the floor pixel 
Visible through the leftmost screen pixel 


[| yma fixed point number representing the y coordinate of the floor pixel 
visible through the leftmost screen pixel 


‘| W— the width of the viewport 


Here's the argument list from the program: 


ARG row:WORD,screenptr:0WORD,texturelist:DWORD,floormap:DWORD, 
Litelevel :DWORD, bots: DWORD,xinc: DWORD,yine: DWORD,«:DWORD,y:DWORD,w: WORD 


I'll explain the details of some of the more esoteric of these parameters as we go. 

We'll need to use a lot of CPU registers in this function, so many that we 
wont be able to use BP to access the parameters after the main loop begins. So 
well move all of the parameters into either registers or memory locations, where 
they can be retrieved later: 


mov bxX,W 

mov Cwidthl,bx 

mov ebx,litelevel 
mov Clightindex],ebx 
moy Ox,row 

mov Crownum],bx 

mov  CLeolnuml,0 

mov  e@cx,¥ 

mov  edx,x 

Lfs s1,screenptr 
mov ebx,xine 

mov Cxincrement],ebx 
mov ebx,yine 

moy CLyincrementl,ebx 
moy ebx,texturelist 
mov Ctexturel,ebx 
moy ebx,bots 

mov  CLbotptrJ,ebx 

Les bp,floormap 

xOr Bax,PaXx ; Clear out EAX 
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Don't worry about the details of the above. I'll show you where the variables have 
been stashed as we use them. 

Now were ready to dive into the main loop. The main loop here is 
considerably longer than in drawwall(), s0 we wont unroll ir completely. Instead, 
well unroll it eight times. Nonetheless, we'll put it in a macro, to save typing, 
We'll call that macro FLOORLOOP: 


FLOORLOOP MACRO REP 


This macro takes one parameter, REP We'll set this equal to the number of times 
the macro has been repeated in the unrolled loop. The first time we call it, REP 
will be 0. The second, it will be 1. And so forth, up to the eighth time, when it 
will be 7. [Il show you what this parameter does in a moment. 

We also need to establish a local address label in the macro. A local address 
label is a label that exists only within the macro. It ceases to exist the moment the 
macro is over, [his avoids conflicts that could result when the same label name 
appears in multiple macro calls: 

LOCAL SKIPPIXEL 


This label will be used a bit later in the macro. 

Earlier, | mentioned a parameter that points to an array containing the bottom 
positions of every wall in every column of the viewport. We'll use this array to 
determine whether we should draw a floor pixel in any given column of the 
current row. We can find out by comparing the number of the current row, 
which has been saved in the memory location ROWNUM, with the byte value 
stored in the current entry in this array, which is pointed to by the far pointer in 
the memory location BOTPTR. We'll put BOTPTR in the gs:bx registers, load 
the bottom position for the current column into AL, get the number of the 
current row in BX, and compare the two. If the row number isnt greater than the 
bottom of the wall, we'll jump over most of the code that follows, to the address 
represented by the local label SKIPPIXEL. This will circumvent ad! of the pixel 
drawing code for this column: 

Lgs bx,Cbotptr] ; Get pointer to BOTS array 
moy al,gs:Cbx] |; Get current bottom position 
mov bx,Crownum] ; Get current row number 


cmp «oal,bl ; Compare the two 
ja SKIPPIXEL ; Jump if floor pixel behind a wall 


Now were going to perform some fairly heavy calculations to find the color of 
the Hoor pixel visible through the current column in the row. We already know 
the coordinates of this pixel — for the first pixel, the values are passed to this 
function in the x and y parameters, and for additional pixels they'll be calculated 
by adding xine and yine to these values — but we need to determine which 
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texture map, and which position within that texture map, we want to take the 
color of that pixel from. First, we'll need to use the x,y oor coordinates to index 
into the Hoor coordinate array, In C++, indexing into the Hoor map was a simple 
matter of dividing the fine x and y coordinates by 64 to get the x,y coordinates of 
the maze square that the ray is intersecting. We could then retrieve the number of 
the texture map tile from the appropriate element of the two-dimensional Hoor 
array. 

It's not gtite that simple in assembly language. In assembler, we must treat the 
cwo-dimensional floor array a8 a one-dimensional array in which each block of 16 
elements represents a row of the maze. Thus even after we've divided the fine 
coordinates by 64 to get the grid coordinates, we must multiply the y grid 
coordinate by 16 (the width of the foormap) and add the x grid coordinate to it 
to get the actual element of the array representing the floor square. 

This is complicated by the fact that the x and y fine coordinates, which are 
currently stored in CPU registers are in 16:16 fixed point format. So we must 
first use a SHLD instruction to shift the high 16 bits of each of these numbers 
into a second pair of registers. Then well need to shift those numbers back to the 
right six positions to divide them by 64. This is a chance to save a few CPU 
cycles, since a 16-position left shift and a G-position right shift can be combined 
into a 10-position lett shift: 
shld edi,edx,10 : Cint)x / 64 
shid ebx,ecx,10 ; Cintiy / 64 
Next EDI contains the x grid coordinates and EBX contains the y grid 
coordinate. 

The EBX register may have some junk in its high bits, which would not have 
been removed by this shift. Well clear them our by using an AND instruction to 
take the value of the register modulo 16, the breadth of the map: 
and ebx,15 ; Clear out junk in EBX 

Next we'll multiply the y grid coordinate by 16 to get the proper row of the 
map: 
shl ebx,4 ; Multiply y * 16 

The EDI register may have also have junk in its high bits, so we'll clear that 
Out Loo: 
and edi,15 7; Clear out junk in EDI 

Finally, we'll add the row offset and the x grid coordinate together to get the 
offset within the Hoor array of the square being intersected by the current ray; 
add bx,di 3 BE = Cintiy/64*164+Cintix/64 
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The EBX register is now pointing at the offset of current floor tile number 
within the Hoor array. However, we need to add this value to the offset of the 
Hoor array within the current segment before we can actually access the tile. We 
could do this with an addition operation, but thats redundant. The 80x96 
instruction set allows us to use the value in certain registers, including EBC, as an 
index off of the value of another register. This works much the same way that an 
array index, such as the x in bigarray[x], works in C++. 

The offset of the floor array is in BP and the segment of the array is in ES. We 
can add the index in EBX to this address and get the number of the current tile 
like this: 


mov al,es:Cebp + ebxJ] ; Get tile number in AL 


The texturelist parameter mentioned earlier is a pointer to an array with 15 
entries, each containing the oftser into the cexture Map of the upper-left COPer of 
each of the 15 bitmaps that we're using for the walls, ceilings, and Hoors. We've 
stored that pointer in the memory location texture. Now well load the pointer 
into gs:bx: 

Logs bx,Ctextured ; Point GS§:BxX at texture List 


Using the texture number in AL as an index, well get a pointer to the texture 
map for the current floor square: 


mov edi,gs:lebx + (eax * 4)] ;Get pointer to texture map 


The EAX * 4 tells the CPU that we're indexing into an array of doubleword (32 
bit) values, effecting scaling the index by four. 

We'll save the pointer to the texture map temporarily in the memory location 
tectureper for later use: 


mov Ctextureptrid,edi ; Save texture map pointer 


Meanwhile, well calculate the position of pixels within the bitmap that the 
current ray is striking. In C++, we did this by raking the fine x and y coordinates 
modulo 64 to get the coordinates within the texture map. Then we multiplied 
the y coordinate by 320 and added the x coordinate to it to get the actual offset 
into the texture map hile past the offser of the upper-left corner of the bitmap. 
We can do pretty much the same thing in assembly language. First we convert x 
and y into integers in the EBX and EDI registers: 


shld edi,ecx,16 
shid ebx,edx,16 


Then we take x and ¥ modulo 64: 


and edi,463 
and ebx,é63 
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Next, we multiply y by 320: 
imul di,320 

and add x to it: 

add di,bx 


Finally, we load the pointer to the upper-left corner of the bitmap into gs:br: 


los bx,Ctextureptrd 
and use DI as an index into the texture map array to fetch the color of the 
current pixel: 
mov al,gs:Cbx + dil 

We can lightsource this pixel the same way we did when drawing the walls, by 
petting a pointer to the lightsourcing array In gs:bx and using AX as an index oft 
ot this pointer to get the proper lightsourced color: 


lgs bx,CLightIndexd 
mov al,gs:Cebx + eax 


The last step is to put the pixel on the display at the address pointed to by fs:si 
plus the value of the REP parameter: 
mov fs:Csi + repl,al 

This brings us to the local SAIPPEXEL label, where we would have ended up 
if this pixel had been behind a wall: 
SKIPPIXEL: 

Before the loop can repeat, we must advance the pointer to the array of wall 
bottoms to the next column: 
add dword ptr Cbhotptrd,1 
and add the x and y increments to the fixed point coordinates of the current floor 
pixel, to derive the address of the next floor pixel in sequence: 


add ecx,Cyincrement] 
add edx,Cxincrementl 


And thar ends the macro: 
ENDM 


To use this macro in the arawfloerrow() function, we simply repeat the macro 
eight times, like this: 


floor: 
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FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 


Notice that the value of the REP parameter is increased once for each call of the 
macro, so that the screen index that we used to place the pixel at the proper 
position on-screen will advance by one for each iteration of the unrolled loop. IF 
we neglected to do this, the foor would appear as a series of diagonal stripes, 
each separated from the next by seven black background pixels. 

We arene quite done yet. Well usually want to repear this loop more than 
eight times, because our viewport will usually be wider than eight pixels. (Note, 
however, that it must always be a mwu/tiple of eight pixels in width, because of the 
way the loop has been unrolled.) Before the loop can repeat again, we must 
advance the position of the screen pointer in SI by eight positions: 
add 51,8 


During the initialization portion of this function, we created a variable called 
coluwm and set it to 0, This variable represents the number of the screen column 
in which the next pixel is to be drawn, On each iteration, well need to add 8 to 
this value: 
add (Ccolnumd],& 


We also need to see if colnum exceeds the width of the screen as specified in 
the w parameter, which weve stored in memory location width: 
mov bx,Ccolnum] 
emp 6x,Lwidtht 

lf it doesn't, we loop back and execute the e1ght unrolled Hoor drawing loops 
again: 
16 Tloor 

Thats tt. We can close up shop and go home: 


pop bp 
ret 
_drawfloorrow ENDP 


The complete text of the drawfleorrew() function is in Listing 12-8. The text of 
the FLOORLOOP macro is in Listing 12-9. 
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i Listing 12-8 The crawfloorrowl function 


_orawfloorrow PROC 
ARG row: WORD,screenptr:DWORD,texturelist:DWORD,floormap:DWORD, 
Litelevel :DWORD,bots: DWORD,xinc:DWORD,y inc: DWORD,x:DWORD,y:DWORD,w: WORD 
push bp ; Save BP 
mov b6p,sp sSet up stack pointer 
; Move parameters into memory variables: 
mov bx,W 
mov Cwidthl,bx 
mov ebx,lLitelevel 
mov (Clightindex],ebx 
mov bx,row 
mov Crownumd,bx 
mov Ceolnum],0 
mov  ecx,¥ 
mov edx,Xx 
lfs s61,5c¢reenptr 
mov ebx,xinc 
mov Cxincrement],ebx 
mov ebx,yine 
mov  Cyincrement],ebx 
mov ebx,texturelist 
mov Ctexture),ebx 
mov ebx,bots 
mov Cbhotptrd,ebx 
les bp,floormap 
Kor e€8X,G8x ; Clear the EAX register. 


floor: 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
FLOORLOOP 
add si,8 ; Advance screen pointers 
add Ceolnum],& : Increase column count 
moy bx,Ccolnum] ; Have we covered entire viewport? 
emp bx,Cwidth 
jb floor : If not, do it again. 


; Unroll FLOORLOOP 8 times. 


pop bp : Else return to caller. 
ret 
_drawfloorrow ENDP 









FLOORLOOP MACRO REP 
LOCAL SKEIPPIXEL 
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Listing 12-9 The FLOORLOOP macro 


Los bx,Cbotptrd ; Get pointer to BOTS array 
mov al,gs:Cbx] ; Get current bottom position 
mov bx,Crownumd ; Get current row number 

emp al,bl ; Compare the two 

ja SKIPPIXEL ; Jump if floor pixel behind a wall 
shld edi,edx,10 > Cintix / 64 

shld ebx,ecx, 10 ; Cintiy / 64 

and ebx,15 ; Clear out junk in EBX 

shl ebx,4 : Multiply y¥ * 16 

and edi,15 ; Clear out junk in EDI 

add bx,di ; BX = Cintdy/64* 164 intix/ da 


mov al,es:Lebp + ebxJ] ; Get tile number in AL 

Los bx,ltexturel ; Point GS:8X at texture list 
mov edi,gs:Cebx + (eax * 4)] ;Get pointer to texture map 
mov (Ctextureptrd,edi ; Save texture-map pointer 
shld edi,ecx,16 ; Calculate Cint)yt64*35204+x264 
shld ebx,edx, 16 

and edi,63 

and ebx,é63 

imul di,320 

add di,bx 

los bx,CtextureptrJ ; Get pointer to texture 

mov al,gs:Cbx + dil ; Get pixel color 

los bx,ClLightIndex] ; Point to Lightsource table 
mov al,qs:Cebx + eax] ; Get Lightsourced color 

moy fs:Csi + repl,al ; Put in on sereen 


SKIPPIXEL: 
add dword ptr Cbotptrl,1 |; Advance bottom pointer 
add ecx,lLyincrementJ ; Add increments to get 
add edx,Cxincrement] ; next pixel coordinates 
ENDM 


The draweeilrow function is so nearly identical to the arawfoorraw function 
that theres no need to print it here, though it can be found in the RAY.ASM fle 
in the OPTIMIZE directory on the accompanying disk. The only significant 
difference is that an array of the top positions of walls is used instead of an array 
of bottom positions to determine if a pixel needs to be drawn. 
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The Optimized draw _maze() Function 


The optimized version of the @raw_maze() function ts essentially the same as the 
lightsourced version in chapter 11. The main difference is that fixed point 
numbers and operations have been substituted for all feat values (with one 
exception, involving the use of the arctangent function, which is difficult to make 
table-driven), In addition, calls to the three assembly language functions have 
been substituted in place of the code that drew the wall columns and the floor 
and ceiling pixels. 

I wont detail every change, but I'll give you some examples. For instance, the 
original lightsourced @raw_maze() function initialized the Hoating point variables 
x and y to the position of the viewer like this: 
float x=xview; 
float y=yview; 


In the fixed point version, the Hoat variables x and y become the fixed point 
variables fix_x and fix_y. (Note the use of the prefix fv as a simple method of 
distinguishing fixed point variables from non-fixed point variables.) In order to 
initialize these hxed point variables, the values of xview and yview must first be 
converted to fixed pointe: 


Long fix_x=(LlLong)xview<<SHIFT; 
long fix_y=(long) yview<<SHIFT; 


Similarly, when the original lightsourced version rotated a ray through a screen 
pixel, it did it like this: 
int x2 = -1024 * (sintradians)); 
int ye = 1024 * (cos(radians)); 
When the fixed point version does this, it uses a table look-up and our fixed 
point multiplication function: 


fixmul (-2546L<<SHIFT,SIN(@degrees) }>>SHIFT; 
fixmul (256L<SHIFT,COS(degrees) }>SHIFT; 


int x2 
int ¥2 


The shifts in this equation may seem a bit confusing. The first converts 256 (an 
arbitrary length for the line to be rotated, as was the 1024 in the earlier version) 
inte a Axed point number. This could be done by hand, but irs easier to let the 
computer do it, since most compilers will perform this operation at compile tume 
rather than runtime, so that we wont waste extra CPU cycles. The shift at the 
end of the line converts the value of the entire expression back to an integer, for 
storage in x2 and xy. 

Other changes in the function follow this basic design. The complete text of 
the optimized draw _ maze) function appears in Listing 12-10. 
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Listing 12-10 The optimized draw_mazel) function 


int getdistance(long degrees,int column_angle,long x,long y, 
int xview,int yview); 


unsigned char bottoms(320],tops€320); 


void draw_maze(map type map,map_type floor,map_type ceiling, 
char far *screen,int xview,int yview, 
long viewing angle,int viewer_height, 
int ambient_lLevel,unsiqned char far * textmaps, 
unsigned char Litesource[MAXLIGHT+1JLPALETTESIZEI, 
unsigned char *litelevel) 


// Draws a faycast image in the viewport of the maze represented 
// in array MAPCIJ, as seen from position XVIEW, YVIEW by a 

// worewer Looking at angle VIEWING_ANGLE where angle 0 is due 

ff north. CAngles are measured in radians. } 


{ 
‘/ Variable declarations: 
int sy,offset; // Pixel y position and offset 
Long fix_xd,fix_yd; ff Distance to mext wall in x and y 
int grid_x,grid_¥; ff Coordinates of x and y grid Lines 


long fix_xcross_x,fix_xcross_y; // Ray intersection coordinate 
Long fix_ycross_x,fix_ycross_y; 


unsigned int xdist,ydist; ff Distance to x and y grid Lines 
int xmaze,ymaze; // Map Location of ray collision 
int distance; f/f Distance to wall along ray 

int tmcolumn; ff Column in texture map 


int top,bot; 
Long fix _yratio; 


/? Loop through all columns of pixels in viewport: 
for (int column=VIEWPORT_LEFT; column<=VIEWPORT_RIGHT; 
column++) { 


f/ Calculate horizontal angle of ray relative to 
‘/ center ray: 
int column_angle=atan( (float) (column-160) 
/ VIEWER_DISTANCE)*(NUMBER_OF DEGREES/6.28); 
if (column_angle<0) column_angle+=NUMBER_OF_DEGREES; 
if (column_angle>NUMBER_OF_DEGREES-1) column_angle-= 
NUMBER_OF DEGREES; 


/! Calculate angle of ray relative to maze coordinates 


int. degrees=viewing_angletcolumn_angle; 
if (degrees>NUMBER_OF_DEGREES=<1) degrees-=NUMBER_OF_DEGREES; 


Orrin oe next purer 
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confined fram previews page 
// Rotate endpoint of ray to viewing angle: 
int x2 = fixmul (-256L<<SHIFT,SIN(degrees) )>>SHIFT; 
int y2 = fixmul (256L<SHIFT,COS (degrees) )>SHIFT: 


// Translate relative to viewer's position: 
KE+=KVIEWS 
¥et=y¥viewW; 


‘i Initialize ray at viewer's position: 
Long fix_x=(Long)xviews<SHIFT; 
Lang fix_y=(long)yview<<SHIFT; 


// Find difference in x,y coordinates along ray: 
Long xdifft=x2-xview; 
long ydift=y2-yview; 


‘i Cheat to avoid divide-by-zero error: 
if (xdiff==0) xdiff='; 
if (ydiff==0) ydiff=1; 


// Get slope of ray: 
Long fix_slope = fixdivi(long) ydif f<<SHIFT, 
CLong)xdiff<<SHIFT); 


‘/ Cast ray from grid Line to grid Line: 
for Css) i 


ff If ray direction positive in x, get next x grid Line: 
if (xdiff>0) grid_x=(C fix x>>SHIFT) & OxffcO) + 64; 


ff If ray direction negative in x, get last =x grid line: 
else grid_x=((fix_x>>SHIFT) & OxffcO) - 1; 


ff If ray direction positive in yy, get next y grid Line: 
if (ydiff>0) grid_y=((fix_y>>SHIFT) & OxffcO) + 64; 


ff lf ray direction negative in ¥, get Last y grid Line: 
else grid_y=((fix_y>>SHIFT) & OxffcO) = 1; 


ff Get x,¥ coordinates where ray crosses « grid Line: 

Tix_xcross_x = (long) grid_x << SHIFT; 

fix_xcross_y = fix_y + fixmul (fix_slope,((long)grid_x 
<<SHIFT)-fix_x); 


‘/ Get x,y coordinates where ray crosses y grid Line: 

fix_ycross_x=fix_xtfixdivé(((long)grid_y<<SHIFT)-fix_y), 
fix_slope); 

fix_yeross_ y=(Long)qrid_y<<SHIFT; 


f/f Get distance to x grid Line: 
fix_xd=fix_xcross_x-fix_x; 
fix_yd=fix_xcross_y-fix_y; 





} 
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distance-getdistance(degrees,column_angle, 
fix_xcross_x,fix_xcross. ¥,xView,¥VIeW)- 
xdist=distance; 


f/f Get distance to y grid Line: 

fix_xd=fix_yeross x-Tix_x; 

fix_yd=fix_ycross_y-Tix_y; 

Long temp fl=fixmul(fix_xd,fix_xd); 

long temp_f2=fixmul(fix_yd,fix_yd) ; 

distance=getdistance(degrees,column_angLe, 
fix yeross x,fix_ycross ¥,xVview,yview); 

ydist=distance; 


ff If = grid line 1s closer... 
af (xdist<ydist) f 


ff Calculate maze grid coordinates of square: 
xmaze=fix xcross_x>>22; 
ymaze=fix_xcross_y>>22; 


ff Set x and ¥ to point of ray intersection: 
Tix_x=fix_xcross_x; 
Tix_y=fix_xcross_y; 


ff Find relevant column of texture map: 
tmcolumn = (fix_y>>SHIFT) & Ox3f; 


ff Is there a maze cube here? If so, stop looping: 
if (mapCxmazellCymazel) break; 

} 

else { ff If y grid Line is closer: 


‘/ Calculate maze grid coordinates of square: 
xmaze=fix_yeoross_x>>22; 
ymaze=fix_ycross_y>>22; 


ff Set x and ¥ to point of ray intersection: 
TIX_X=T1Ve_yeross_x; 
fix_y=fix_ycross_y; 


‘f/f Find relevant column of texture map: 
tmcolumn = (fix _x>>SHIFT) & Ox3f; 


‘/ Is there a maze cube here? If so, stop looping: 
if (mapCxmazeJ][ymazel]) break: 


} 


f/f Get distance from viewer to intersection point: 
distance=getdistance(degrees,column_angle, 


Tix_x,fix_y,xview,¥View) } 


if (distance==0) distance=1; 


Optimization 


CORN a rel page 
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connanéd from previeus page 
‘f/f Calculate visible height of wall: 
int height = VIEWER_DISTANCE * WALL_HEIGHT / distance; 
if ('height) height=1; 


ff Calculate bottom of wall on screen: 
bot = VIEWER_DISTANCE * viewer_height 
/ distance + VERT_CENTER; 


/f Calculate top of wall on screen: 
top = bot - height + 1; 


// Initialize temporary offset into texture map: 
int t=tmcolumn*320+IMAGE_HEIGHT; 


// Tf top of current vertical Line is outside of 
//f viewport, clip it: 
Long dheight=height; 
Long theight=IMAGE_HEIGHT; 
Long fix_yratio=fixdivé (long) WALL_HEIGHT<<SHIFT, 
(Longdheight<<SHIFT);: 
if (top < VIEWPORT_TOP) f{ 
int diff=VIEWPORT TOP-top; 
dheight-=diff; 
theight <= (diff*fix_yratio)>>SHIFT; 
top=VIEWPORT_TOP; 
} 
if (bot == VIEWPORT_BOT) f 
int diff=bot-VIEWPORT_BOT; 
dheight -= diff; 
theight -= diff*fix_yratio>>SHIFT; 
t<=(diff*fix_yratiod>>SHIFT; 
bot=VIEWPORT_BOT; 
} 


‘/ Save top and bottom in arrays: 
topsCcolumnJ=top; 
bottoms€CcolumnJ=bot; 


‘/ Point to video memory offset for top of Line: 
offset = bot * 320 + column; 


ff Which graphics tile are we using? 
int tilecmapCxmazelJLymazeJ-1; 


ff Find offset of tile and column in bitmap: 
unsigned int tileptr=(tile/5)*320*  1MAGE_HEIGHT+(tiled5) 
WIMAGE WIDTH+t; 


Long fix_increment=fixdiv( iheight<<SHIFT,dheight<<SHIFT); 
int Level=LitelevelCdistancel+ambient_level; 
if C(lLevel>MAXLIGHT) Level=MAXLIGHT; 
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drawwall(&(screenLoffsetl) @(textmapsltileptrd),dheight, 
fix_increment,&(LitesourcelLlevel J(Z0])); 


f/f Step through floor pixels: 
for Cint row=VERT_CENTER+5; row<=VIEWPORT_BOT; rowt++) { 


ff Caleulate horizontal angle of Leftmost column relative 
‘f to center ray: 
int column_angle=atan( (float) (VIEWPORT_LEFT—HORI?Z CENTER) 
/ VIEWER_DISTANCE)* (NUMBER OF DEGREES/6.28); 
if (column_angle<0) column_angle+=NUMBER_OF_DEGREES; 
if (column _angle>NUMBER_OF DEGREES-1) column_angle-= 
NUMBER_OF_ DEGREES; 


ff Calculate angle of ray relative to maze coordinates 

int degrees=viewing_angle+column_angle; 

if (degrees>NUMBER_OF_DEGREES-1) degrees-= 
NUMBER_OF_DEGREES; 


‘/ Get ratio of viewer's height to pixel height: 
Long fix_ratio=fixdiv¢((lLong)viewer_height<<SHIFT, 
Clong) (row-VERT_CENTER)<<SHIFT); 


‘/ Get distance to visible pixel: 
Long fix_distance=fixdivifix_ratio*VIEWER_DISTANCE, 
COS(columnangle)); 


‘/ Rotate distance to ray angle: 
int Left_x = = (fixmul(fix_distance, SINC degrees) )>>SHIFT?}; 
int Left_y = fixmul(fix_distance,COS(degrees))>>SHIFT; 


‘i Translate relative to viewer coordinates: 
Left_x+=xview; 
Left_yt=yview; 


ff Calculate horizontal angle of rightmost column relative 
ff to center ray: 
column_angle=atan( (float) (VIEWPORT_RIGHT-HORI?_ CENTER) 
/ VIEWER_DISTANCE)*(NUMBER_OF_DEGREES/6.28); 
if (columnm_angle<0) column_angle+=NUMBER_OF_DEGREES; 
if (column_angle>NUMBER_OF_DEGREES-1) column_angle=-= 
NUMBER_OF_DEGREES; 


‘i Calculate angle of ray relative to maze coordinates 
degrees=viewing_angle+column_angle; 
if (degrees>NUMBER_OF_DEGREES—-1) degrees-= 

NUMBER_OF DEGREES; 


‘f/f Get ratio of viewer's height to pixel height: 
fix_ratio=fixdiv((Long)viewer_height<<SHIFT, 
(Long) (row-VERT_CENTER)<<SHIFT); 


COMET yd rid of Meee Pare 
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continued From previo page 


‘f/f Get distance to visible pixel: 
fix_distance=fixdivi fix_ratio*VIEWER_DISTANCE, 
COS(column_angle)); 


‘/ Rotate distance to ray angle: 
int right_x = - (fixmul(fix_distance,SIN(degrees))>>SHIFT);: 
int right_y = fixmul(fix_distance,COS(degrees))>>SHIFT; 


// Translate relative to viewer coordinates: 
right_x+=xview; 
right_yt=yview; 


ff Calculate stepping increment: 

long fix_x_increment=fixdiv( (long) (right_x-left_x)<<SHIFT, 
(Long) (VIEWPORT_RIGHT-VIEWPORT_LEFT)<<SHIFT); 

long fix_y_increment=fixdiv(( long) (right_y-Left_y)}<<SHIFT, 
(Long) (VIEWPORT_RIGHT-VIEWPORT_LEFT)<<SHIFT); 

long fix_x=(€Long) Left_x<<SHIFT; 

Long fix_y=(Long) Left_y<<SHIFT; 


int lLevel=LitelevelCfix_distance>>SHIFTJ+ambient_lLevel ; 
1f Clevel>MAMLIGHT) Level=MAXLIGHT; 


drawfloorrow(row,&(screenLrow*3204+VIEWPORT_LEFT]), 
&(textureList(O]),@¢(floorlOI00]), 
E(LitesourcellevelJCO]), 
E(bottomslVIEWPORT_LEFTI),fix_x_increment, 
Tix_y_increment,fix_x,fix_y,VIEWPORT WIDTH}; 
} 


‘/ Step through ceiling pixels: 
for Crow=VERT_CENTER=5; row>=VIEWPORT_TOP; frow) 


ff Calculate horizontal angle of leftmost column relative 
// to center ray: 
int column_angle=atan( (float) (VIEWPORT_LEFT-HORIZ CENTER) 
/ VIEWER_DISTANCE)*(NUMBER_OF_DEGREES/6.28): 
if Ccolumn_angle<0) column_angle+=NUMBER_OF_DEGREES; 
if (column_angle>NUMBER_OF_DEGREES-1) column_angle-= 
NUMBER_OF_DEGREES; 


// Calculate angle of ray relative to maze coordinates 
int degrees=viewing_angle+tcolumn_angle; 
if (degrees>NUMBER_OF_DEGREES-1) degrees-= 

NUMBER_OF_ DEGREES; 


// Get ratio of viewer's height to pixel height: 
Long fix_ratio=fixdivillong) (WALL HEIGHT-viewer_height? 
<<SHIFT, (long) (VERT_CENTER-row)<<SHIFT); 


‘/ Get distance to visible pixel: 
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Long fix_distance=fixdiv( fix_ratio*VIEWER_DISTANCE, 
COS(column_angle??); 


ff Rotate distance to ray angle: 
int Left_x = — (fixmul (fix_distance,$SIN(degrees) }>=>SHIFT); 
int left_y = fixmul(fix_distance,COS(degrees) )>>SHIFT; 


ff Translate relative to wiewer coordinates: 
Leftt_x+=xview; 
Left_yt=yview; 


f/f Calculate horizontal angle of rightmost column relative 
ff to center ray: 
column_angle=atan( (float? (VIEWPORT_RIGHT-HORIZ CENTER) 
/ VIEWER_DISTANCE) *(NUMBER_OF_DEGREES/6.28); 
if Ccolumn_angle<0) column_angle+=NUMBER_OF_DEGREES; 
if (column_angle>NUMBER_OF_DEGREES-1) column_angle-= 
NUMBER_OF DEGREES; 


‘/ Calculate angle of ray relative to maze coordinates 
degrees=viewing_angle+column_angle; 
if (degrees>NUMBER_OF_DEGREES-1) degrees-= 

NUMBER_OF DEGREES; 


‘f/f Get ratio of viewer's height to pixel height: 
fix_ratio=fixdiv( (long) (WALL_HEIGHT-viewer_height)<<SHIFT, 
(Long) (VERT_CENTER-row)<<SHIFT)- 


‘f Get distance to visible pixel: 
fix_distance=fixdiv(fix_ratio*VIEWER_DISTANCE, 
CO$(column_angle)); 


‘f Rotate distance to ray angle: 
int right_x = -(fixmul (fix_distance,SIN( degrees) )>>SHIFT); 
int right_y = fixmul (fix_distance,COS(degrees) )>>SHIFT; 


‘/ Translate relative to viewer coordinates: 
right_xt=xview: 
right_yt=yview; 


‘/ Calculate stepping increment: 

Long fix_x_increment=fixdiv¢ (long) (right_x—lLeft_x)<<SHIFT, 
(Long) (VIEWPORT _RIGHT-VIEWPORT_LEFT)<<SHIFT) = 

Long fix_y_increment=fixdiv( (long) (right_y-left_y)<<SHIFT, 
(Long) (VIEWPORT_RIGHT-VIEWPORT_LEFT)<<SHIFT); 

Long fix_x=(Long) lLeft_x<<SHIFT; 

Long fix_y=( long) lLeft_y<<SHIFT; 


int Level=LiteLevel Cfix_distance>>SHIFTJ+ambient_level; 
if Clevel>MAXLIGHT) tevel=MAXLIGHT; 


drawceilLrowlrow,&(screenLrow*320+VIEWPORT_LEFTJ), 
B{texturelistlLO]) ,6(ceilLingLOJ[O]), 


ceutraearet ore BLE (Pater 
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E(litesourcellevelJCO]), 
&(topsCVIEWPORT_LEFTJ),fix_x_inecrement, 
fix_y_ increment, fix_x,fix_y,VIEWPORT_WIDTH) ; 


} 


int getdistance(long degrees,int column_angle,long x,long y, 
int xview,int yview) 
{ 
long trig,fix_ny,fix_nx; 
int distance; 


Int c=degrees/512; 
if COCcR3)==0)| | (Cc83)==3)) 
distance=abs(fixdivi(y=(C Long) yview<SHIFT) )>SHIFT, 
COS(degrees-T026*¢*?2) *COS( column_angle)>>SHIFT); 
else 
distance=abs( fixdiv((x-(( Long) xview<SHIFT) )>SHIFT, 
SINGdegrees-1024*%c%2))*COS(column_angle)>>SHIFT}; 
return(distance); 


The Optdemo Program 


We need a demonstration program to show off the capabilities of our new 
engine. This demo will be based on the demo program used in our earlier 
animations, It will use the event manager that we developed back in chapter 3 to 
detect input events, which will allow the user to explore the ray-cast maze. 

We really need only one new capabiliry here. In our earlier animations, we 
used the built-in BIOS timer to set the frame rate of our programs. But the BIOS 
timer doesnt have a high enough resolution for the timing that we need now; it 
doesnt slice time into small enough fractions of a second. 

Instead, well use the HTIMER routines developed by Mark Betz for my 
earlier book, Flights of Fantasy (Waite Group Press, 1993). These timer functions, 
designed to be called from C++, allow us to time events down to millionths of a 
second. The HTIMER routines can be found on the disk in the file 
HTIMER.CPP along with the fle HTIMER.DOC. 

The timing will work a bit differently here too. Instead of maintaining a 
steady number of frames per second, well try to eke out as many frames a second 
as we can, But on faster machines, less time will pass between the frames — and 
that will be reflected in our demo in that we'll move the viewer a small distance 
between frames the faster the frame rate gets. We'll base this movement distance 
on the time between frames returned by the HTIMER routines. 
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As a result, the specd with which users move through the maze will be 
independent of the speed of their machine. Owners of slow machines will cover 
exactly as much ground per second as will owners of fast machines. However, 
those with fast machines will see more frames per second, making the animation 
appear much smoother and more realistic. 

In order to use the HTIMER routines, we must create an instance of an 
HTIMER object: 


HTimer timer; 


To start the timer running, we invoke the timerOn() function, which requires 
no parameters: 


timer).timerOn(); 


When we want to know how much time has passed since we turned the timer 
on, we use the timerOf() function, passing its value to a long variable: 


elapsed_time = timert.timerOff(); 


The time is returned in microseconds — that is, millionths of a second. 

This gives us a simple way to time a frame: Use timerOn() before the frame is 
drawn, timerOH() before we start the next frame. We can then use the value of 
elapsed_time to calculate how far the Viewer should move berween frames, by 
creating a pair of constants called DISTANCE PER SECOND and 
ROTATION_PER_SECOND to tepresent the number of coordinates that we 
want the user to traverse In one second and the number of degrees (in our 4096- 
degree system) that we want the user to rotate in a second, respectively: 


const DISTANCE _PER_SECOND=128; 
const ROTATION _PER_SECOND=10e4; 


We can then calculate the actual distance traveled by dividing the distance per 
second by one million to get the distance per microsecond and multiplying ir by 
the number of microseconds in elapsed_time, 

Long néew_y=CLong) (DISTANCE PER_SECOND/1000000.0 
*elapsed_time)<<SHIFT; 

This value is converted into a hxed point number to facilitate the next step in 
determining the viewers new position, which is projecting an imaginary point in 
front of the viewer, rotating to the viewers orientation, and scaling it to the 
viewers position, just as we rotate and scale rays in the ray-casting function: 


xvViewt+=Cfixmul (new_x,COS(viewing_angle)) 
-Tixmul (new_y,SIN(viewing_angle)))>>16; 

y¥viewt=(fixmul(new_y,COS(viewing_angle)) 
*fixmulinew_x,SIN(viewing_angle)))>>14; 
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To move the viewer backwards, we just make the new_y value negative. 

A similar series of operations can be used to rotate the viewer. We divide 
ROTATION PER SECOND by 1 million, then multiply ic by elapsed_time. 
The resule is added to viewing_angle, the variable thar tells us which way the 
viewer is facing: 
viewing_angle+=(( float ROTATION_PER_SECOND/1000000.0 

*elapsed_time) ; 


In case the angle has become less than 0 or greater than 4095, we check for 
wraparound: 


if (viewing_angle>NUMBER_OF_DEGREES=1) 
viewing angle—-=NUMBER_OF DEGREES: 


The rest of the optimized maze demo is pretty much the same as the earlier 
demos, except that weve added a pair of functions called AddFrame Time() and 
PrintFrameRate(), adapted from similar functions written by Mark Betz for 
Flights of Fantasy. The first of these functions maintains an array of 500 frame 
times, as calculated between frames by the HTIMER routines. When the 
program terminates, PrintframeRate() is called to average these values and 
calculate the average time between frames and the average frame rate per second, 
and prints these values on the display. 


The complete text of the OPTDEMO.CPP module appears in Listing 12-11. 





Listing 12-11 The OPTDEMO.CPP module 


// OPTDEMO.CPP 

i 

‘/ Calls optimized ray-casting function to draw Lightsourced 
‘/ view of maze. 


fi 

// Written by Christopher Lampton for 
// Gardens of Imagination (Waite Group Press, 1994) 
Hinclude <stdio.h> 

Finclude <dos.h> 

Finclude <conio.h> 

Finclude <stdlib.h> 

Hinclude <math.h> 

Winclude "“screen.h" 

Finclude “optdemo.h" 

Hinclude “pex.h" 

Hinclude "“raycast.h" 

Finclude “evntmgrl.h" 

Finclude “bitmap.h” 

Winclude “jo.h" 
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#include "trig.h" 
Finclude "“types.h" 
Finclude “htimer.h" 
#include “fixpoint.h” 


f/f Funetion prototypes: 
void PrintFrameRate(}; 
void near AddFrameTime(long elapsedtime); 


/f Constant definitions: 

const MAXFRAMES=500; 

const NUM_IMAGES=15; 

const float MULTIPLIER=3; 

const DISTANCE PER_SECOND=128; 

const ROTATION_PER_SECOND=1024; 

const WHICH_EVENTS=KEYBOARD_EVENTS+MOUSE_ EVENTS; 


map_type walls=¢ 


Ce ep ep ely ay fe epee eette Egcep ee Betts 
{-9. 2,0, 2, 0, 0, 0, 2, 0, O, 0; 0; 0; 0, 0, 23. 
(9, 0, 0. 0, 0, 0, 0. 2. 8.0, 0, 0, 0, 6, 0, 23, 
C9, 6, G,.0, 0,60, G,.0,-8, 6,0, 0,0, 0, 0, 2h, 
(9. 0; 05.05 05-0, 0,0, 0,6, 2; 2:0; 0-0; 35, 
C9, 0,-0, 0, 0,0, 0: 2 6, 0, 2; 2,-0, 0, 0, 23, 
{ 3, 0, 0, 0, 0,0, G, G, 0, 0, 0, 9,9, 0, 0, 2}, 
i ?, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 0, 2}, 
{-2, 2, 2, 0, 0; 0, 0, 0; 0, 0, O, 9, 9, O, O, 2, 
{s, 6, 0, 0, 0, 0, 6,-0,. 0, 2,2, 2,-0, 0, 0,25, 
{2, é, @, 0, 0, 0, 2, 2, 0, 2, 0, 0, 0, 0, 0, ed}, 
C750; 0;-0: 0:0. 2, 2: 8,.27 8 0: 0; 0. 6,33, 
C7, 0,0, 0, 0.-0, O,-2,0, 0,0, 0,-0, 0,.°0,. 24, 
{ 7, 0, 0, 0, 0, 0, 0, 2, 0, 2, 0, 0, 0, 0, 0, 2}, 
Cr ts Feat Fhe a. 2h. =, 6, 0, 0; G, 2), 
C2, 2s 25:25 tte 2pckp tp aeiee fect, poke ee 
}; 
map_type flor={ 
Lty Gp Oy ty ty €7 Oy Cp Cp 2p fy 2, 2, 2, €y £3; 
Ger ee ee ne ae ee ea ce Re ee a A i Ey 
C2 ap poly ep iey Zpttg ey 2p be Ep dp be ta ety 
Ce pe yp 2, @, 2, 2; 2, 2, 2, £2, 2, 2, 2, fy 2; 2}, 
C3290 28 Bae Se eee. FS eB 
ey Ep op Oe Oe oe ee bene Be eae Cp epee ee Dees 
Ley Of Se Fe Dp Bp Dep Op Ly Cy Ly 2, Cy Cy Cy Et, 
C22 eh oe Boe eee Bore a Sy 
Lehi p tp eke he te be egies Lyte ee ep ees 
(226: Be eR! Ba a a 
CO eptk yp be Bp ey Beep hep egies Eeiky epee ess 
tt, Oy Oy Oy Cy fy Cr ty Oy Cy Cy 2, 2, Cy 2, 2}, 
C20 20 B00. Bo eee Bee Bees 2 
Lite Be Spe rleples Cf lp er fe es Cp ee ee ee er 
td, 2, @7 ty Oy fy C7 fy Oy Oy Oy Op Cy Cy Ly CT, 


COME MA OF RUE Pudge 
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}; 

map type ceiling=¢ 
Coo Se oe, OS, SF, Le 9, 9, 8, 3, 8, FF, 9, FF; 
{9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9 9, 9, 9, 9, FI, 
{9, 9, 3, 9 9,9, 9, 3, 9, 9, 3, 9,9, GS, 9, Ft, 
19, 9, 9, 9, 9, Fe Fe Pe Pe Fe Pe Fe Fe Fe Fe FF, 
co ee, ee ee. FF a a oS, Fo SE; 
{9,9, 9%. 9, 9, 9% 9, 9 9, 9, 9, 9, 9, 9, 9, OF, 
co, 9, 3, 9, F.9, 9,9, 9,3, 2 3-03, Fe Sy Ft, 
if, Fe FP, Fe Fe Fe Fe Fe Pe Fe Fe Fe Fe Fe Fe FH, 
eee SS ee Fee oe ee Re ee Pe ae 
(9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9. 9, 9, 9, 9, Of; 
i 9, 9, 9, 9, 9, F, 3, Pe Fe Fp Fe Fe Fe Fe Fe FF, 
ee ee ee ee ee a ee ee a 
ae ee ee Pe ee ee ae a 
(9, 9, 9, 9, 9-9, 9,9, 9,9, 9, 97-9, 9, 3, SI, 
{?, 9, 9, 9 9, 9, Fe PF, Fe Fe Fe Fe FP, PF, F, FT, 
co, 9D 3 8, FES, 9 PES, 8, OF, 9 

I; 


pcx struct textmaps,bg; // PCX files for tiles and background 
FILE *handLle; ff Handle for Lightsourcing file 
unsigned char LitetableCMAXLIGHT+1JLPALETTESIZEJ; 

unsigned char *Litelevel; 

unsigned char *texturelistl15J; 


Long viewing_angle=13; 

Long intensity=MAXLIGHT; 
Long viewer_height=32; 

Long ambient_level=MAXLIGHT ; 
long xview=8*64+32; 

Long yview=8*64+32 ; 


HTimer timer; ‘/ instance of HTimer object 
HTimer® timer2; // pointer to HTimer abject 
Long elapsed_time; 

unsigned long framelLMAXFRAMESI; 

int frameptr=U; 

int framewrap=0; 


void mainCint arge,char® argvLl]) 
1 


event_struct events; 
unsigned far char *screen_bufter; 


// Read arguments from command Line if present: 
if Cargc>=2) intensity=atoflargvLl1J); 
if (arge>=3) ambient_level=atof(argvl2]); 


// Load texture map images: 
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if (LoadPCX("walls.pcx",&textmaps)) exit(1); 


‘/ Load background screen image: 
if (lLoadPCX("demobgS.pcx",fbg)) exit(1); 


ff Create texture List array: 

for Cunsigned int i=0; i=NUM_IMAGES; i++) ¢ 
texturelistliJ=8(textmaps.imagel(1/5)*320*644145*641); 

} 


// Load Lightsourcing tables: 
if (Chandle=fopen("Litesore.dat","rb"))J==NULL) ¢f 
perror("Error'); 
exit; 
} 
fread(litetable,MAXLIGHT+1 ,PALETTESIZE,handle) ; 
fcloseChandle); 


/f Initialize array of Light levels: 
Litelevel=new unsigned charCMAXDISTANCEI; 


// Calculate Light intensities for all possible 

if distances: 

for Cint distance=1; distance=<MAXDISTANCE; distancet++) f{ 
float ratio=(float)intensity/distance*MULTIPLIER; 
if Cratio=1.0) ratio=1.0; 
LitelevelLdistancel=ratio*MAXLIGHT; 

} 


ff Point variable at video memory: 
char far “screen=(char far *)MK_FP(Oxa000,0); 


ff Create offscreen video buffer: 
if ((screen_buffer=new unsigned char C64000])==NULL) {; 
perror("Error’); 
exit; 
} 


ff Allocate memory for timer object: 

if (Ctimer2 = new HTimer()) == NULL) f 
perror("Initialization of timer object failed”); 
exit; 

} 


‘/ Initialize event manager: 
init_events(); 


‘/ Calibrate the user's joystick: 

1f C(WHICH_EVENTS & JOYSTICK_EVENTS) ¢{ 
printf(’\nCenter your joystick and press button "); 
printTt("one. in}; 
setcenter(J; // Calibrate the center position 
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printf("Move your joystick to the upper Lefthand "); 
printf? corner and press button one.\n'"): 

setmin(); ‘ff Calibrate the minimum position 
printf("Move your joystick to the Lower righthand "): 
printf("corner and press button one.\n"); 

setmaxt); ‘/ Calibrate the maximum position 

} 


// Save previous video mode: 
int oldmode=*Cint *)MK_FPCOx40,0%49) ; 


{f/f Set mode 14h: 
setmodetOx13); 


// Set the palette: 
setpalette(textmaps.palette); 


// Clear the screen: 
cls(screen_butfer); 


/! Copy background into screen buffer: 
for (i=0; i1<64000; i++) 
screen_butferlil=bg. imagelil; 


‘/ Draw initial view of maze: 

draw_maze(walls,flor,ceiling,screen_buffer,xview,yview,viewing_angle, 
vViewer_height,ambient_lLevel,textmaps. image, 
litetable,Litelevel); 


fi Put screen buffer contents on screen: 
putwindow(0,0,320,200,screen_buffer); 


events.quit_qame-0; 
timer).timerOnt); 


‘f Let's go for a walk in the maze: 
while(!events.quit_game) f{ 


‘/ Draw the maze in screen buffer: 
clrwin€VIEWPORT_LEFT,VIEWPORT TOP,VIEWPORT WIDTH, 
VIEWPORT_HEIGHT, screen_butfer}; 


elapsed_time = timerl.timerOff(); 
AddFrameTime(lelLapsed_t ime); 
timer]. timerOnt); 


ff Put first frame into buffer: 
draw_maze(walls,flor,ceiling,screen_butfer,xview,¥V¥1ew,VTewing_angle, 
viewer_height,ambient_Level,textmaps. image, 
Litetable,litelevel); 
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‘f Bove screen buffer to screen: 
putwindow( VIEWPORT _LEFT,VIEWPORT_TOP,VIEWPORT_ WIDTH, 
VIEWPORT HEIGHT, screen_but fer); 


‘/ Move viewer according to input events: 
getevent(WHICH_EVENTS, events) ; 


‘/ Did @ go forward event occur? 
if (events.go forward) f 


‘/ If so, assume viewer 15 standing at origin of map... 
Long new_x=0; 


ff ...facing north. Calculate destination by checking 

/f timer to see what fraction of a second has passed 

ff since Last frame of animation: 

Long new_y=(long) (DISTANCE_PER_SECOND/ 1000000.0 
*elapsed time)<<146; 


// Rotate destination to actual viewer heading and 
// translate relative to actual viewer position: 
xviewt=( fixmul (new _x,COS(viewing_angle)) 
=—fixmul(new_y,SIN(viewing_angle))}>>16; 
yviewt=(fixmul (new_y,COS(viewing_angle)) 
+fixmul (new x,SIN(viewing_angle)))>>16; 
} 


ff Bid a go back event occur? 
if Cevents.go_back) f 


// Repeat procedure for forward event... 
Long néew_x=0; 


ff ...-but make the distance negative, to the rear 

ff of the viewer: 

Long new_y=-( Long) (DISTANCE_PER_SECOND/ 1000000.0 
*elapsed_time)<<14; 


// Rotate and translate destination as above: 
xviewt=C(fixmul (new_x,COS(viewing_angle)) 
=—fixmul(new_y,SIN(viewing_angle)))}>>16; 
yviewt=(fixmul (new_y,COS(viewing_angle)) 
+fixmul (new_x,SIN(viewing_angle)))>>1é4; 
} 


f/f Did a go right event occur? 
if <events.go_right) f 


‘/ If so, calculate new angle based on elapsed time since 
‘* Last frame of animation: 


cotnrend on meat pape 
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} 


Viewing angle+=(( float) ROTATION PER SECOND/1000000.0 
*elapsed_time); 


‘/ Wrap around to 0 if angle exceeds maximum degrees: 
if (viewing _angle>NUMBER_OF DEGREES-1)} 
¥iewing_angle-=NUMBER_OF_DEGREES; 
} 


ff Bid a go left event occur? 
if Cevents.go_left) { 


f/f If so, calculate new angle based on elapsed time since 

ff Last frame of animation: 

viewing_angle=-=(( float) ROTATION_PER_SECOND/1000000.0 
*elapsed_time); 


‘/ Wrap around to maximum degree if angle less than zero: 
if (viewing_angle<0) viewing_angle+=NUMBER_OF_DEGREES; 
} 
} 


ff Reset video mode and exit: 
setmode(oldmode); 
PrintFrameRate(); 


void PrintFrameRate() 


{ 


int numframes; 
unsigned Long Looptime = OQ; 


if (framewrap) numframes = MAXFRAMES; 
else numtrames = frameptr; 
cprintt("Average time per frame (ms):"); 
if (numtframes) { 
for (int 7 = 0; 1 <= numframes; i++) Looptime += framelid; 
Looptime /= numframes; 
eprintT(" 4i\rin", looptime); 
printf("Average frames per second: 4d",7000/looptime); 
} 
else cprintf(" timer disabled\rin"); 


} 


void near AddFrameTime( long elapsedtime) 
{ 


framelframeptr] = Celapsedtime/ 1000); 
frameptr++; 
if (frameptr == MAXFRAMES) f 
frameptr = QO; 
framewrap = -1T; 
} 
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Running OPTDEMO.EXE 
To run OPTDEMO, go to the OPTIMIZE directory and type: 


OPTDEMO 


Youll see a view of the maze similar to ones displayed by our earlier ray-casting 
programs, but this time you can move through the maze using the cursor keys. 
The (1) cursor key moves forward, the @) cursor key moves backwards, the 
cursor key rotates lett, and the cursor key rotates right. The key 
terminates the animation. 

OPTDEMO accepts two parameters: the first a value in the range 0 to 32 
representing the level of the viewers torch, the second a value in the same range 
representing the level of the ambient lighting. Both of these are set to 32 — full 
brightness — by default, but you can play with other light levels by setting these 
to lower values. 

Figures 12-4a—-d show views of the maze from various angles and lighting. 
Have fun exploring’ 


Optimization Review 


Weve covered a lot of material in this chapter. Lets look back briefly over the 
optimization techniques that were discussed: 
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Figure 12-4a View of the maze from GPTDEMO 
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Figure 12-46. Second view of the maze fram OPTDEMG 





Figure 12-4¢ Third view of the maze from OPTDEMO 
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Figure 12-40 Fourth view of the maze from OPTDOEMO 


Translating into Assembly Language. Although this isn't a trick that beginning 
programmers should attempt on their first foray into game programming, 
medium-level and advanced programmers will find that this is a rellable way of 
achieving those last few ounces of animation speed. Remember, however, that 
this technique should be restricted only to the most time critical portions of 
your program. 


Unrolling the Loop. By “unrolling" a loop — that is, converting a loop toa 
sequence of repeated instructions — extremely time-critical inner loops can be 
speeded up significantly, especially if the number of instructions in the loop is 
relatively small, However, it isn't nécessary to unroll a loop fully. Unralling it 
eight times and placing the resulting code inside another loop will give you 
most of the benefits of an Unrolled loop without many of the associated 
problems, such a$ bloated code and overflowing CPU caches. Remember to 

Use macros to reduce both typing and typos. 


Table Look-Ups. lf there aré complex calculations, such as trigonometric 
functions, in time-critical portions of your code, consider precalculating all the 
possible results, placing them in an array, and simply retrieving the appropriate 
Value at runtime to save calculating overhead. Not all complex Functions lend 
themselves well to table look-ups — square roots, for instance, are difficult to 
do this way — but trig functions can be sped up a hundredfold through 
precalculation. 


Fixed Point Arithmetic. The standard floating point functions that came with 
your compiler can sometimes be quite slow, especially if there's no math 
coprocessor in the user's computer. Fixed point arithmetic, which handles 
fractional values using standard integer operations, can be much faster. Note, 
however, that this may not be true much longer, as Pentium-based computers 
Iwhich come with extremely fast built-in math coprocessors) become 
increasingly Common on gameplayers’ desktops. 


— ——— 
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Finally, remember that knowing where to optimize is as important as knowing 
how to optimize. The secret? Look for deeply nested loops and put your 
optimization resources inside them. A code profiler, such as the Turbo Profiler 
that comes with Borland C++, can also be useful in locating performance 


bottlenecks. 
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Cc now have al nearly complete ray-casting engine, capable of 
drawing column by column the floor, ceiling, and walls of an 
environment described in the computer's memory as a series of 
two-dimensional arrays. What are we going to do with this 
engine? Well, we could use it to create a virtual reality program 





in which users walk through an imaginary environment defined by its Hoors, 
ceilings, and walls. And thats essentially what we're going to do, except that this 
imaginary environment will be used in the larger context of a computer game. 
While we wont present a complete game here, we'll give you all the tools that 
youll need to design your own. And we'll create a kind of virtual reality 
application to demonstrate those tools. 

In this chapter, we'll look at ways in which our ray-casting engine can be used 
to generate graphics for a computer game. We'll need to add one more feature to 
our engine before such games become possible. That feature will add objects, 
both moving and stationary, to our imaginary world. This will allow us in turn to 
populate a maze with objects such as treasures (which the player can collect for 
additional points) and monsters (which the player must destroy in order to 
complete his or her exploration of the maze). 

The problem with adding objects to our maze is that the code required to add 
such objects necessarily constitutes a kludge. Alweee (pronounced “klooge’) is a 
term popularized by progammers in the post World War II era to describe 
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program features that are neither elegant nor simple to code. Kludges make 
a program complex and, well, ugly, bute they are sometimes necessary to make 
the program run well, Up until now, our ray-casting engine has been remarkably 
simple and elegant. But now we have to recognize the requirements of real-world 
game programming and add some rather awkward features to our engine. 


Adding Objects to the World 


There are several methods that we could use to add objects to our “world.” For 
instance, we could create a two-dimensional “object map” array, similar to the 
wall, floor, and ceiling arrays that weve used up until now, that would indicate 
where each object is located within the maze. [his would allow us to identify the 
location of objects during the wallcasting portion of the ray-casting process. Each 
object that we find while casting for the nearest wall could be pushed onto a stack 
— a data structure from which objects are removed in the opposite order from 
that | in which they Were recorded, OT “pushed,” onto the Structure — and then 
removed from the stack 1 IT] FevVCTsec order to be drawn T1 the display. However, 
this would greatly slow down the ray-casting process, since each object would be 
encountered by several rays — one for each column in the width of the displayed 
object — and would therefore be processed in a thoroughly redundant manner, 
once for every ray that struck the object. In fact, this is how we draw walls in our 
current ray-casting system, But drawing objects using the same method might 
take up too much time for our purposes, 

A better way to identify objects would be to create a “visibility array,’ with one 
element for each square in the maze. All elements of this array could be set to 0 
before ray casting begins. Then, during the ray-casting process, we can note 
which maze squares are visible by placing non-zero values in the appropriate array 
elements. When ray casting is complete, we can check this array to see which 
squares are visible and consult an “object array’ to determine if those squares 
contain objects. If they do, those objects can be drawn by a special object- 
drawing function. The problem with this method is thar the visible squares may 
not be completely visible; that is, portions of these squares may be obscured by 
walls that lie closer to the viewer, so that the objects in these squares are only 
partly visible. How does the object-drawing function know whether it is to draw 
an entire object or only part of an object? 


Hidden Surface Removal 
By and large, this second method provides the more efficient way to draw objects 
(though don't let this stop you from searching for more efficient methods of 
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rendering objects using other algorithms). Using this method, we can search for 
visible squares during the ray-casting process, recording the identity of visible 
SQ LAPS in aT] array that we ll al © up explicitly for that purpose, then draw the 
objects once the walls, Hoors, and ceiling are drawn. 

Unfortunately, this algorithm opens a Pandoras box of problems, which can 
collectively be referred to as bidden surface removal problems. We've mentioned 
these problems earlier, but we haven't really tackled them. In the polygon-fill 
graphics that I discuss in Flights of Fantasy, | treat this problem in some detail; 
but in ray casting it rarely comes up. One of the major advantages of the ray- 
casting process is that the programmer never has to worry about whether one 
surface is in front of another, since the ray-casting process invariably identihes 
those surfaces that are closest to the viewer. For instance, if one maze block is 
partially obscured by another maze block, the rays cast from the viewer's position 
will inevitably strike the object that is visible through the current column of the 
viewport. No specihe code for hidden surface removal is necessary. 

But when we populate the maze with objects, mobile or otherwise, hidden 
surface removal immediately rears its ugly head. lf we were dealing with polygon 
graphics, there would be no elegant solution to this problem (though a number 
of inelegant solutions are discussed in Flights of Fantasy). Fortunately, ray casting 
lends itself to some relatively simple solutions to the hidden surface problem. 
Because we are only dealing with rwo-and-a-halt-dimensional graphics — that ts, 
graphics in which only the x and y maze positions are variable and tn which the 
vertical positions ot all objects are fixed a= WE Can COME up with simpler 
solutions to the hidden surface problem than if we were dealing with true three- 
dimensional objects of the sort considered in Flighes of Fantasy. 

When we cast a ray through a column in the viewport, we learn the distance 
of the nearest wall visible through that column. If there are objects nearer to the 
viewer than that wall, chen they will be visible and should be drawn on top of the 
wall in that column. If there are objects farther from the viewer than that wall, 
then they are not visible through that column and should nor be drawn (see 
Figure 13-1). 

Although this is a simple enough way to regard the hidden surface removal 
problem, it still treats those surfaces on a column-by-column basis. A given 
object may be visible through column A, but the same object may be blocked by 
a wall in column B (see Figure 13-2). As noted earlier, we could treat the hidden 
surtace removal problem Ol a column-by-column basis, but the resulting code 
would be unnecessarily slow. We can draw objects much faster if we draw the 
objects all at once, after the ray casting is done, Bur how can we then determine 
which columns in the bitmapped images of those objects are visible and which 


are not? 
(25, 
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Figure 13-1 Wall 8 is farther fram the viewer than object A, 
but wall C is closer 
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Figure 13-2 The object is visible through 
viewport column A, but not through 
column 6 
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Column-by-Column Drawing 

We can reach a fairly agreeable compromise berween drawing an object a column 
at a time and drawing objects all at once: That solution ts to record the hidden 
surface removal information while we draw the individual columns of the wall 
through wallcasting, then use that information to determine which columns of 
an object are visible and which are not during the drawing of each object. 

As confusing as that may sound, its not hard to implement in computer code. 
In mode 13h, there can be at most 320 columns of pixels in the viewport. When 
we cast rays through each of these pixel columns to determine the distance of the 
nearest wall column, it's a simple Matter to record the distances to these wall 
columns in a 320-element array, in which each column represents a column of 
the viewport. We can then use this information to determine which surfaces are 
hidden and which surfaces are visible when drawing objects, 

Thus we can create an array with 320 elements called dist[] thar will contain 
the distance of the nearest wall, viewed from the current viewing angle, for each 
column in the viewport. (As a practical matter, well maintain an element for 
every column on the mode 13h screen, but only those in the viewport will 
actually be used. This will allow us to resize the viewport dynamically, as 
requested by the user.) 


The distancel) Array 


The distance|] array will be created in the draw_mraze() function, in the 
OPTRAY.CPP module. Every time a wall is detected while casting a ray through 
a column in the viewport, the distance of that wall will be recorded in the 
element of array distance corresponding to that column of the display. For 
instance, if the ray cast through column 200) on the display strikes a wall at a 
distance of 389 Hoor pixels from the screen, array element dist|200] will be set 
equal to 389. This is simple to add to the draw_miaze() function, like this: 


distCcolumnJ=distance; 


where column is the column through which the most recent ray was cast. This 
line appears in the code three lines after the ray casting is finished. See the 
module FINALRAY.CPP in the GARDENS directory on the disk. 

To determine which objects are (potentially) visible in the current viewport, 
well create an array called visible[][], where each element will correspond to a 
square in the current maze, The two elements in brackets following the visible 
array Nalmie will correspond co the X,Y Mdee coordinares of the sQubare through 
which a ray is being cast. For example, if the square at maze coordinates 7,4 is 
visible, then the array element visible[7][4] will be set equal to a value of -1, the 
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standard notation for “true.” Later (as you'll see in a moment) we'll check for this 
value to see if the maze square at 7,4 (or any other location) is visible. The code 
for setting this element of the visible array to -1 will also be placed in the 
draw_maze() function as represented in the FINALRAY.CPP module. As each 
maze square is detected during the wallcasting process, the equivalent element of 
the visible array will be set to -1. 

When do we actually draw the objects? We could do so immediately after the 
wallcasting process is complete, but the Hoorcasting and ceilingcasting processes 
would then overwrite portions of the object images. lt would be better to wait 
until all of these processes are complete. That way, the images of the objects will 
sit neatly on top of the Hoor and ceiling images. Although this involves some 
redundant pixel drawing — we ll be erasing Hoor and ceiling (not ro mention 
wall} pixels by overdrawing them with the pixels in the objects ao Its actually 
easier to alae the objects Over the walls than to draw only those portions of the 
Hoors, walls, and ceilings that will not need to be overdrawn by objects. 

(Nore that whats easier about this process is the programming itself. The 
reader 1s encouraged to come up with algorithms that will prevent drawing 
portions of the walls, floors, and ceilings that will later be overdrawn by objects 
from being drawn in the first place. This may make the code more complicated 
— not to mention harder to understand — bur it could save time in the drawing 
itself and increase the frame rate of the resulting animation.) 

Thus we'll place the object-drawing code at the very end of the draw_prazel') 
function. Because we've recorded the distance information for the individual 
columns on the display, the function that actually draws the objects — which 
well call ebjdraiw() — will do the hidden surface removal. In the draw _maze() 
function, we need only worry about where the object is to be drawn on the 
display. We'll then call objanaw() to perform the actual drawing. 


Representing Objects 


Before we can draw the objects, however, we'll need a means of representing 
them. First, as noted above, well create an object array, which will be ininalized 


in the main module of our game, GARDENS.CPP like this: 
map type ob jmap= 


£ 0, GO, O, 0, 0, 0, 0, 0, G,-0, 0,0, 0, 0,0, , 
. 0, 6, 0, 0; 60; 0; 0,0, 6,6, 0; 0, 0,-.0,.0, UF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, O, O, 0, O, OF, 
£0; O,:0, 1; 0,0, 0,0, G, 0, 0, 0, GO, 0,.0, 0, 
{O, 0, O, 0, 0, 0, 0, 0, 0, O, 0, O, 0, 0, 0, OF, 
{ 0, 0,0, 6, 0, 2, 0,.0, 0, 0, 0,0, O, 0, 0, O}, 
c 0, G,.0, 0, 0, 0, 0, 0, G, 0, 0, 0, 0, Gd, 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, O, OF, 
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{ 6,:0, 6, 0, 0, 0, 0, 0, 0, 0, 0,0, 0, 0,. 0, OF, 
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, 
{ 0,0. 0, 0, 0, 0,0, 0, 0, DO, 0, 0, DB, 0, 0, OF, 
{ 6, 0, 0, 0, 0, 0,0, 0, 0, 0, 0, 0, 0, 0, 0, OG}, 
£0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, U0, 0, OF, 
{ 0, 0, 0, O, 0, 0, 0, O, 0, O, 0, O, 0, 0, O, 03, 
{ 0,-0, 0,0, 0, 0,.0, 0, 0, 0,.0, 4, O, 0, 0, Oo, 
{ 0, 0, 0, 0, 0, 0, -0, 0, 0, 0, 0, 0, 0, 0, 0, 0) 


tage 
i. 


Each element in this array corresponds to a square in the maze, according to 
the same system used in the wall, ceiling, and Hoor arrays that we developed in 
earlier chapters. [fan element is ser to 0, there is no object in that square of the 
maze. If it's non-zero, there ts. For instance, if an element is set to 1, then we 
know that object 1 resides in that square. 

How do we know what object | is? We'll create a separate array of structures 
to hold that information. The structures in the array will be of type objtype, 
which will be defined in the OBJORAW.H hie like this: 
struct objtype f 

int screenx,screeny; 

int mazex,mazey; 

int whit,hbit; 

int wdraw,hdraw; 

unsigned int distance; 

int imagenum; 
ty 
The screenx,screeny fields hold the screen coordinates of the upper-left corner of 
this object as it will appear on the video display. This value will be calculated in 
the course of the code that follows. The mazex,mazey fields, which indicate the 
location of the object within the maze, will be filled in as the object is initialized 
in the GARDENS.CPP module. (I'll show you this code in a moment.) The 
whit,hbit fields represent the width and height of the bitmapped image of the 
object, as its stored in memory. (For all of the objects that well use, these will 
both be equal to 64, making the width and height of the object bitmaps the same 
as for the bitmaps we're using for walls, Hoors, and ceilings.) The wdraw and 
hdraw fields are the width and height of the bitmaps for the objects as they'll 
actually be drawn on the display. These heures will be calculated just betore the 
objects are drawn and will be subject to clipping against the sides of the viewport. 
The distance held, which contains the distance from the viewer to the object, will 
also be calculated just prior to drawing. And the imagenum field corresponds to 
the index within an array of bitmapped object images that will be used to draw 
the objects on the display. 

We can then initialize an array of these objects at the beginning of the 
GARDENS.CPP module: 
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objtype objLJ=f 

{0,0,5%64,5%64,64,64,0,0,0,0,0}, // Skull 
{0,0,3*644352 ,3*%644+52 ,64,64,0,0,0,0,3}, /f Column 
I; 


The first line of figures represents the state of the “skull” object. Some of these 
helds will be calculated later, as noted above, These are given an initial value of 0, 
However, the object's mazex and mazey fields are both initialized to 5*64, which 
will put the object in the maze square with coordinates 5,5. (We multiply this by 
64 because these coordinates are In the hne coordinate SVStem af the Maze rather 
than the maze square coordinate system.) The owo fields set to 64 represent the 
dimensions of the bitmap associated with the object. The final number is the 
number of the element in the bicmap array that contains the bitmapped image of 
the object. Well now create thar array. 

We'll set aside memory for the array that will hold the bitmapped images of 
the objects, like this: 
char far *imageCNUMIMAGES]; 


This creates an array of pointers to type char called image. 

The images of the objects will be stored on disk in a PCX fle called 
OBJS.PCX. We can load it using the PCX loader that we developed earlier in 
this book. However, instead of leaving the P(CCX in its image buffer and extracting 
the images directly from the butter to the display, we'll copy each 64 by 64 image 
into its own 4096-byte buffer. We'll then set the individual elements of the image 
array to point to those buffers, so that we can retrieve the images later. This saves 
us some memory and simplifies the process of calculating the position of the 
image. 

Here are the instructions that read the PCX file and copy the image data into 
the individual image bufters: 

if CloadPCXC"objs.pex",So0bjs)) exitt1); 


for (unsigned int i1=0; i1<NUMIMAGES; i++) 
{ 
if (Cimagelil=new unsigned charl4096])==NULL) 
exitcl); 
for {unsigned int j=0; j<64; j++) f 
for (unsigned int k=0; k<64; k++) 
jmagel i JCke*644jl=objs.imagel((i/5)*320%644+(725) 
*64+j+k*320)1; 
} 
} 
} 


delete(logo. image); 





———— — 
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These instructions are in the GARDENS.CPP module. The NUMIMAGES 
constant is defined in the GARDENS.H header file and represents the number of 
64 by 64 object images that are present in the OBJS.PCX file. The for() loop 
iterates once for each of these images, first allotting a 4096-byte buffer in which 
to store the image (and pointing the equivalent member of the images array to 
that buffer), then looping through the pixel data for the image and copying that 
data into an element of the image array, where the image data will be stored for 
the reset of the program. The delete Statement recurs the 64-kilobyte bufter used 
by the PCX file back to DOS, so that we can reuse it later for additional PCX 
images that well be loading on a temporary basis. (More abour these images in a 
moment.) 

Now we can begin actually drawing the objects. 


Drawing the Objects 
Well walk through the object-drawing function itself in a moment. First, lets 
take a look at the code that calls that function. The code that calls the object 
drawing function will be placed at the very end of the drew_maze() function. It 
will first iterate through the visible() array to determine which squares in the 
maze can actually be seen: 
for (xsquare=0; xsquare«146; xsquare++) f{ 

for Cysquare=0; ysquare<16; ysquaret+) { 

if (visible[xsquarel[ysquare]) f{ 

If a square is visible, we'll proceed to determine if it contains an object and, if so, 
where on the video display the object should be drawn. First, we'll get the 
number of the object from the objmap|| array that we established earlier: 


int objnum=objmapCxsquarelJ[Cysquared; 


lf the object number in the specified array element is 0, then there's no object 
there. [f it’s zat 0, we'll continue to process the object that we've found there: 


if Cobjnum) { /f If object 


The image-drawing code, having determined that a ) is present in one of the 
visible squares, now prepares to draw that object. First, the object number must 
be decremented by one: 
~-ob jnum; 

Why must we decrement the object number? For the same reason that we 
decrement the tile number for a wall after it has been extracted from the wall 
array. We identify the presence of objects in the object map by looking for values 
that arent 0. This means that there cant be any 0 objects in the map. However, 
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there és a 0 object in the object array. Thus, we must represent 0 objects in the 
object map as object 1. This in turn pushes all other object numbers up by a 
count of 1. Therefore, when extracting these numbers from the array, we must 
decrement them co COMPOCn sate, 

To simplify subsequent code, we'll create a pair of integer variables called x and 
yto hold the x,y coordinates of the object within the maze grid: 


int x=objlobjnum] .mazex-xview; 
int y=objCobjnum].mazey-yview; 


Now comes the trickiest part of the object-drawing code. In order to 
determine the screen coordinates at which the object must be drawn, we must 
rotate the object around the viewer until it is aligned with the viewers coordinate 
position. [his subject was discussed in some detail back in chapter 7. To align an 
object with the current viewing position, we must rotate it around the viewer by 
the megative of the viewers current rotational position. (Readers who find this 
concept a bit hazy are urged to read Flights of Fantasy, where the subject of 
aligning objects with the viewer position was discussed in great detail.) We can 
perform this rotation with these instructions: 
int alignx=(x*C0S(-viewing_angle) 

= w*SIN(=-viewing_angle))>>14; 
int aligny=(x*SIN(-viewing_angle) 

+ y*COS(-viewing_angle))>>16; 

You'll recall from chapter 7 that these equations rotate an object around an 
origin position (that is, the 0,0 point relative to which the object coordinates are 
defined). All of the objects in our maze are defined by a two-dimensional 
coordinate POSITION, $0 this ts all we need do to adjust their coordinates relative to 
the current viewing position. (If we were dealing with three-dimensional, rather 
than two-and-a-half-dimensional, graphics, we would also need to rotate the 
coordinates around the y and z axes of our coordinate system.) The variables 
alignx and aligny tell us where the object is, or would be, if the viewer were 
rotated to angle 0 — directly facing north along the y axis — within the 
coordinate system. 

Since this operation realigns the objects as though we were facing northward 
along the positive y axis, we can tell if the object is behind us or in front of us by 
checking to see if its y coordinate is positive or negative (see Figure 13-3). If irs 
positive, the object is in front of us. If its negative, the object is behind us. Thus 
we will only proceed with our drawing code if the object's y coordinate is 
positive, that is, if the object is in front of us: 


if Caligny>=0) f 


OF course, this problem should have been solved by the earlier if statement 
that only accepted squares marked as visible, so this code is a bit redundant. Its 
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Figure 13-3 When facing northward along 
the positive y axis, the value of the y 
coordinate tells us if an abject is in front of 
us (positive coordinate) or behind us 
(negative coordinate) 


probably possible to remove the visibility marking code without penalty, though 
this is left as an excercise for the reader. 

We'll use the familiar Pythagorean method to determine how far away each 
object is: 


distance=sort((longialigqnx*alignx+(long)aligny*aliqny?; 


This assigns the distance of the object, in maze pixels, to the integer variable 
distance that we defined earlier in the anaw_ maze) function. 

We can now project the objects position onto the video display using a 
standard perspective equation. Interestingly, its only necessary to project the 
object's x coordinate onto the display, since this is the only position that’s actually 
variable within our two-and-a-half-dimensional coordinate system: 


int projx=alignx*VIEWER_DISTANCE/distance+HORIZ_CENTER; 


Now we need to determine the horizontal and vertical size of the object as it will 
be displayed. We can do this with the standard perspective equations too: 
objCobjnum].wdraw=ob job jnum].wbhit*VIEWER_DISTANCE/ 

distance; 
objCobjnum].hdraw=objCobjnum] hbit*VIEWER_DISTANCE/ 

distance; 
This code sets the wdraw and hdraw felds of the object structure, which 
represent the width and height of the object on the display, to the appropriate 
perspective-adjusted values. 
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We also need to determine the x and y coordinates on the display at which the 
upper-left COMMer of the objects image should be drawn, A moment dfo, we 
calculated the x and y coordinates at which the object will be displayed, in the 
variables alignx and aligny. But these are the coordinates of the center of the 
object (see Figure 13-4). To determine the coordinates of the upper-left corner of 
the object, we must subtract half of irs width and height from this value and 
center it vertically around the VERT_CENTER of the display (as defined in the 
GARDENS.H header file): 


obj Lobjnuml.screenx=—-projx-objlobjnum].wdraw/2; 
ob jCobjnum]. screeny=VERT_CENTER=objCobjnum].hdraw/2; 


Now well add the number of the object to the list of objects to be drawn, 
which well maintain in an array called objlist: 
obj lListCnumob js+4+J=ob jnum; 

The wzmodbjs variable was established back before we began looping through 
the objects, like this: 
int numobjs=0; 


By incrementing the value of awmodys every time an object number is added to 
objlist, we know how many objects are currently visible. 
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Figure 13-4 The x,y coordinates mark the 
center of the object. Before we draw it, we 
must calculate the coordinates of its upper- 
left comneron the display 
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The Painter's Algorithm 


We're done compiling the objects list. (I'll spare you all of the closed curly 
brackets that are necessary to terminate the loops that we started in this process.) 
Now We Can Starla new loop that actually draws the objects. 

First, however, we need to perform some more hidden surtace removal. Earlier, 
we developed a method for detecting whether a given column of an object's 
bitmap is behind or in front of a wall, for any given column of the viewport. 
However, we also need to know if one object is in front of another object. To 
determine this, we ll use a technique called the Painter's Algorithm. 

The Painter's Algorithm gets its name from the idea that painters, when 
rendering a landscape, paint background objects first, then paint foreground 
objects over the background objects. Translated into computer rendering terms, 
the Painters Algorithm says that we should draw objects in the background 
before we draw objects in the foreground, so that objects in the foreground will 
be drawn on top of background objects, 

This requires that we perform an operation known as a depth sort. A depth sort 
takes all of the objects that are visible (or porentially visible) on the display and 
sorts them into a list with the objects most distant from the viewer at the 
beginning of the list and the objects closest to the viewer at the end of the list. If 
we then draw the objects in this order, it is guaranteed that foreground objects 
will be drawn on top of background objects. 

In a polygon graphics system of the type that is used in most flight simulators, 
this depth sort may sort objects into the wrong order. This is because polygons 
can be rotated at odd angles to the viewer, allowing background objects to 
obscure foreground objects. The objects that we'll be drawing in this chapter, 
however, will net be oriented at such odd angles. Rather, each object will face 
squarely toward the viewer, with all pixels in the object at the same distance from 
the display (see Figure 13-5). Thus a simple depth sort is all we need in order to 
determine a correct drawing order for these objects. 

We'll use the simplest form of sort, the bubble sort, to arrange the objects in 
the proper tro nt-to-back order: 

if (numobjs) ¢ 

int swap=-1; 
while Cswap) 4 
swap=0; 
for int i=0; i<(numobjs-1); i++) f 
1f CobjlobjlistlLil) distance<objloebjlistlitlli.distance) ¢ 
int temp=objlistlid; 
obj Listlid=sobjlistli+13; 
objlistCi+1J=temp; 


swap=—1; 
} f/f End if 
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+ f/f End for 
+ // End while 
} f/f End if 


This sorting algorithm iterates through the list of objects, swapping pairs of 
objects into the correct order when it finds a pair in which the closer object is 
lower in the list than a more distant object. When all of the swaps are completed 
(as indicated by the swap variable, which is set to -1 when a swap occurs and to 0 
when one has not occurred), the sort terminates. 

For small numbers of objects, the bubble sort does a fine job, For larger 
numbers of objects, the reader is encouraged to find a faster swapping method — 
check any book of computer algorithms for suggestions — and to substitute it 
for the bubble sort. One possibility is the insertion sort, in which the objects are 
inserted in order as the list is compiled, without a separate sorting step. This 
particular sort would be most efficiently performed with a linked list, in which 
each entry has a pointer to the next item, than as an ordered list of the sort we're 
using here, since inserting an item into a linked list is a relatively trivial 
operation, 





Figure 13-5 All of the objects will be facing squarely toward 
the viewer, no matter what the viewer's position 
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Now thar the objects are sorted, we can draw them. The objlist array contains 
the numbers of the object in the order in which they should be drawn; we need 
only iterate through this array: 

for (int 150; t<numobjs; i++) ¢ 

drawobject ((abjCobjlistlil]), VIEWPORT LEFT, VIEWPORT TOP, 
VIEWPORT_RIGHT, VIEWPORT_BOT,distance,screen}; 


+ // End for 
} 


This terminates the draw maze funcoon. You'll notice that the final line of the 
function calls a new function that weve named drawobject(), which (as its name 
implies) does the actual object drawing. Next, we ll look at how this function is 


dehned. 


The drawobject() Function 
The prototype for the drawebject() function looks like this: 


void drawobject(objtype *obj,int lclipx,int Lclipy,int rclipx, 
int rclipy,unsigned int distance,char *screen); 


This prototype, which you can find in the OBJORAW.H file — the function 
itself is in the OBJORAW.CPP file — tells us that the drawebyece() function 
requires these parameters: *obj, which ts a pointer to the objrype structure that 
defines the object; Iclipx, which is the x coordinate of the left edge of the 
viewport; lclipy, which is the y coordinate of the left edge of the viewport; rclipx, 
which is the x coordinate of the right edge of the viewport; rclipy, which is the y 
coordinate of the right edge of the viewport; distance, which is the distance (in 
floor pixels) of the object from the viewer; and *screen, which is a pointer to the 
current video display or video display butter. 

The drawobyject() function first takes the pointer to the bitmap representing 
the object and assigns it to the char pointer bitmap: 


char far *bitmap=imagelob)->imagenum]; 


Next, we determine the scale at which the object is to be drawn in the 
horizontal and vertical dimensions and assign these fractional values to the 
variables fix_wincrement and fix_/increment, just as we did in the last chapter: 
Long fix_wincrement=( float }obj->wbit/obj->wdraw*SHIFT_MULT; 

Lang Tix_hinecrement=( float)obj-—>hbit/obj—>hdraw*SHIFT_MULT; 

These variables, as their names imply, contain fixed potnt values, that is, fractions 
represented as /ong integers. Now we need to determine the position in video 
memory (buffered or otherwise) at which we should begin drawing the object: 


unsigned int scereenstart=ob)->screeny*320+o0b)—>screenx; 
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The variable sereenstart now contains the video memory offset at which drawing 
should begin, 

We'll need a variable to indicate which vertical column of the object's image 
were currently drawing. [his should be initialized to zero: 
unsigned Long column=0; 
The reason that we've used a /omg variable here is that colwma will be treated by 
subsequent code as a fixed point variable. 

Ir would also be useful if we knew how many pixels (that is, bytes) the 
screenstart variable is indented from the left side of the display: 
unsigned int Leftrow=screenstart “* 320; 

Well be drawing the object as a series of columns from left to right. Lers use a 
for{) loop to iterate through the columns: 
for Cunsigned int x=0; x<obj->hdraw; x++) ¢ 

The sereenstart variable tells us where in video memory we should begin 
drawing the object. However, we'll set the variable sp¢r equal to the offset in video 
memory where the next pixel should be drawn: 
unsigned int sptr=screenstart++; 

The variable Sper will be set equal to the column in video memory at which 
the next pixel is to be displayed. Since the variable column is a hxed point 


variable, we'll need to shift the value of column 16 positions to the left ro 
represent the integer value that we re storing in bptr: 


unsigned int bptr=column>>16; 
To advance the variable ca/umin to its next position, we ll need to add the value 
of (fix_wincrement tO It: 


columnt+=fix_wincrement; 


Now, before we begin drawing the object, we need to create two new variables, 
which we'll call dive and dastline: 
unsigned Long Line=0; 
unsigned int lastline=0; 

Now we can set the ansigned integer variable column to point to the upper-left 
corner of the object, by adding x and Jeftrow,: 
unsigned int column=x+leftrow; 

We'll draw the object by iterating from the left clipping parameter to the right 
clipping parameter: 
if (CCcolumnd>lelipx) && (Ccolumn)<rclipx)) f 
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Here the hidden surtace removal comes into play. We should not draw the 
current column at all if there's a wall closer to the viewer than the object: 


if (distance<distECcolumn]) f 


[f the wall is farther from the viewer than the object, well draw the object in 
front of it. To do this, well use a for() loop that will iterate through all of the 
columns that are vistble in the object: 

for Cunsigned int y=0; y<obj->wdraw; yet) { 

int bebitmap[bptrJ; 

if (b) screenCsptrJ=b; 

Line+=fix_hincrement; 

if Clastline!=(Line>>16)) { 
bptr+=obj—>wbit; 
Lastline=lLine>>16; 

} 

sptr+=320; 


The most important line here is the iff) statement if (b) screen[sptr=b;. This 
line checks to see if a pixel is 0 before printing it to the display. Why? Because 0 
pixels in an object image represent transparency. Zero pixels should not be 
displayed; rather, the background pixels behind these pixels should show 
through. If not for these transparent pixels, all objects would be perfectly 
rectangular, which is obviously undesirable. Instead, we allow 0 pixels to be 
transparent. When we detect such a pixel, we dont draw over the background, 
allowing the background to show through. 

And thar, aside from the closing brackets, 1 Is all that there | Is CO drawing 
objects. 


Adding Game Features 


Learning to program isnt all that there is to creating a game. You also have to 
sive some thought — preferably a great deal of thought — to game design. Alas, 
game design is at least as complex a subject as game programming, and really 
deserves a book of its own. We can, however, offer a few suggestions to help you 
get started. 

start by looking at games that you've enjoyed playing. Try to identify the 
features that make those games attractive: graphics, atmosphere, story line, and so 
On. Decide what Rene of fale youd li ke tO create. For example, al) adventure 
game emphasizes exploration and puzzle-solving. In such a game, the player 
needs to acquire the objects necessary to solve a puzzle, and perhaps select actions 
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to be performed on those objects — lift the rock, push the button, open the 
drawer, and so on. In a role-playing game, on the other hand, the player takes 
the part of a character who grows in experience and power while overcoming 
monsters and fulfilling quests. Many successful games (such as the Ultima series) 
combine aspects of both adventure and role-playing. 
Obviously, any game designed around the algorithms in this book will take 
place in some kind of maze. Once you've decided what kind of game you want 
to create, think abour the kinds of objects to be found in that maze. In addition 
to creating pictures for the objects, you'll need to expand the objrype structure to 
account for the important characteristics of objects in your game, For example, 
YOu might add Structure members like these: 
char * name ff name of object 
int owner; ‘/ 0 = unowned, 1 = owned by player 
/f 2-99 owned by monster 

Hint weight f/f how much object weights 
f/f (player can only carry hissher 
ff strength in objects) 


int type // 1 = weapon @ = treasure 3 = food 
if 4-99 = special object 


You could then use auxiliary structures for information specific to particular types 
of objects. For example, a weapon would do a certain amount of damage, food 
might restore a certain amount of the player's strength, and so on. 

You will also need a structure to hold information about the player as 
represented by the “viewpoint character” in the game. Some traditional 
characteristics used in role-playing games include: 
int str // how strong: affects damage done in attacks, 

/f ability to carry objects 
‘/ force doors open, and so on 
int dex // how fast/agile the player is; 
‘/ ability to dodge attacks or traps 


int con ‘/ constitution, or ability to absorb damage 

int hp ‘/ hit points (amount of damage player can take 
‘/ before dying) 

int exp ‘/ experience points (given for accomplishments, 


ff Increases abilities of character) 


You will probably need a structure to hold similar information about 
monsters, though it probably won't be as detailed as the structure for the player. 
Once you've built this “infrastructure” of structures and arrays, you'll need a 
main “command processor” function that interprets the players mouse clicks and 
sends control to the appropriate function, Typical player actions might include: 


=]) Move (click on direction arrows or use keyboard) 





CHAPTER THIRTEEN Putting It All Together 


turn around 


[aa 
—— 


. . 

tel 

F . 
a 


Examine an object 


fell 


Pick up an object 
(=! attack a monster 
al Review information about the player character 
cel Save the game 


and so an. It's up to you whether to use a menu interface or an icon interface, 
but the latter is more popular in contemporary games. Of course, we've already 
provided you with mouse, keyboard, and joystick inpur routines. 

Systems for manipulating objects (and particularly combat and magic systems) 
can become very complex, We recommend YOu Start with simple functions and 
add features only after the game has been tested and is working well. 

Appendix A lists some further readings on game programming and design that 
you may find helpful. 


Bells and Whistles 


Before I'm done, however, Id like to add a few additional bells and whistles to 
our “game,” Specifically, I'd like to add a set of opening credits and an automap. 
First, let's add the opening credits. 


The Opening Credits 
The opening credits will be a series of PCX files displayed one after another. The 
code for displaying each PCX file will be identical to the code for displaying the 


rest. Here's the code for displaying the first credit: 
fadepalout(0,256); 


ff Load Waite Group logo: 
if ClLoadPCK("waite.pex",Glogo)) exit); 


// Copy logo into video memory: 
for €i=0; 1<64000; 14+) 
screenli J=Logo. imageLlil; 


ff Fade logo int 
fadepalin(0,256,logo.palette); 
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‘f Start timer running: 
timerl.timerdn(); 


elapsed _timé = timeri.getElapsed(): 


whileCelapsed _time<TITLE_DELAY) f{ 
if (kbhitt)) ¢{ 
abort_titles=-1; 
break; 


elapsed _ time = timerl.getElapsed(); 
I 


fadepalout(0,256); 
cls€sereen); 


delete( logo. image); 
timerl.timerOfft); 


This code begins with an interesting instruction: fadepalout(0,256);. To what 
does this code refer? It refers to a special set of C++ functions stored on disk in 
the fle PALFADE.CPP. (The header file defining these functions is available in 
the file PALFADE.H.) The code in this fle was written by Mark Betz for Flighys 
of Fantasy. The palfadeout() function fades all of the colors in the current 256- 
color palette to color 0,0,0 — chat ts, black. This causes whatever is on the screen 
when this program is run to fade to black. We then use the foadPCXY) function 
to load the initial credit screen, contained on the disk in the fle WAITE.PCX. 
This PCA image contains a three-dimensionally rendered version of The Waite 
Group logo, created by artist Stephen Blackmon using the rendering program 
Imagine 3,0 from Impulse Software, The for() loop that follows copies this 
bitmap data into video memory, then the fadepalin(0,256,logo. palette) 
Instruction fades this image up on the video display. 

We also use the &4r¢() function to check if the user hits a key while the logo ts 
on the display. This allows the user who has already seen the title sequence 
enough times to memorize individual pixels to abort the credits and proceed 
directly into the game, We also set the abort_titles Hag to -] so that we know to 
skip the succeeding credit screens. 

If the user does wor hit a key, we hold this image on the display for the amount 
of time defined in the TITLE_DELAY constant, using Mark Betzs timer 
routines (introduced in chapter 12): 


elapsed_time = timerl.getElapsed(); 


whileleLapsed_time<TITLE_BDELAY) 7 
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if (kbhitt2) df 
abort_titles=-1; 
Dreak; 
} 
elapsed_time = timer).getElapsed(); 
} 
Then we fade out on these images and clear the display, using the functions in 
PALFADE. CPP: 


fadepalout(0,256); 
cla(screen); 


Finally, we delete the memory necessary for storing the first title screen and turn 
the timer off: 


delete(Llogo. image); 
timerl.timerdtft): 


Then we do the same thing for two more title screens, the first of which contains 
an image of a mountain with the superimposed logo “A Chris Lampton 
Production’ and the second the title of the game itself (see Figures 13-Ga—c for 
the credit images). Note, however, that we now check to see if the abort_titles 
Hae has been set before displaying the additional screens. 


ihe Waite Group Press” 
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Figure 13-6a The Waite Group logo 
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Figure 13-66 A Chris Lampton production, natch 
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Figure 13-6¢ The name of the game 
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fadepalout(0,256); 


if ('abort_titles) f 


} 


// Load mountain Logo: 


if (lLoadPCX("chrispro.pex",Glogo)) exitt Ti; 


/f Copy Logo into video memory: 
for (i=0; i<64000; i++) 
screenliJ=Logo. imagelid; 


ff Fade logo in: 
fadepalin(0,256,lago.palette); 


ff Start timer running: 
timerl.timerOn(); 


elapsed time = timerl.getElapsed(); 
whileCelapsed_time<TITLE_DELAY) ¢ 


if Ckbhitt)) f 
abort_titles==1; 


break; 
} 
elapsed_time = timerl.getElapsed(); 
} 
fadepalout(0,254); 
cla(screen); 


delete(logo. image); 
timerl.timerOff (>; 


fadepalout(0,¢56); 


if (!abort_titles) ¢ 


‘if Load title background: 
if CloadPCX("titlebg.pex",&logo)) exit(1); 


‘if Copy logo into video memory: 
for (i1=0; 1<64000; i++) 
screenliJ=Logo. imagelil; 


ff? Fade Logo in: 
Tadepalin(0,256,logo.palette); 


ff Start timer running: 
timer1.timerOn(); 
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elapsed time = timerl.getElapsed(); 


whileCelapsed_time<TITLE_DELAY) { 
if Ckbhitt)?) ¢ 
abort_titles=-1; 
break; 
} 
elapsed time = timeri.getElapsed()> 
} 


fadepalout(0,256); 
els(screen); 


deletel(logo. image); 


timerld.timerOfft); 


The Automap 


And thats almost all the code we need to complete our “game.” However, theres 
one more element that Id like to add: an automap. 

Whats an automap? The three-dimensional graphics produced by a maze 
game can often be confusing. The player can get lost in all of those three- 
dimensional rwists and turns. An automap is a top-down map of the maze, in a 
format similar to the maps that you get from AAA or your local gas station, 


displaying where the walls are in the maze. We can create one quite easily by 


adding a bit of code to our GARDENS.CPP module, We'll call the automap- 
drawing function drawmap. Here's the code: 


void drawnap(char far *screen) 
t 
unsigned int ptr=MAPY*S520+MAPK; 
for (int x=0; x<16; x++) ff 
for Cint y=0; yel6; y+4+) Tf 
if Cwalls€xJCy]) ¢f 

screen(ptr J=WALL_COLOR; 
screenLptr+1J=WALL COLOR; 
screenLptr+2 J=WALL_COLOR; 
screenLptr+3J=WALL_COLOR; 
screen(ptr+320J=WALL_COLOR; 
screen(ptr+3521J=WALL_COLOR; 
screenLptr+32¢ J=WALL_COLOR; 
screenCptrt+325J=WALL COLOR; 
screenLptr+640 J=WALL COLOR; 
screenLptr+641J=WALL_COLOR; 
screenlptr+642 J=WALL_COLOR; 
screenLptr+643 J=WALL COLOR; 
screenCptr+960 J=WALL_COLOR; 
screenCptr+941 J=WALL_COLOR; 
screenLptr+962 J=WALL COLOR; 
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screenLptr+9645 =WALL_ COLOR; 
} 
ptr+=4; 
} 
ptr+=474520-64; 
} 
} 


The automap() function requires only one parameter: *screen. This tells us the 
address of the video display or screen buffer. The constants MAPX and MAPY 
contain the x,y screen coordinates of the upper-left corner of the automap, which 
the function uses to calculate the video memory offset of the pixel in that corner, 
assigning that offset to the variable prr. The two nested for loops iterate through 
the maze, drawing a white square (the color of which is defined in the constant 
WALL COLOR) wherever it finds a wall. You'll notice that we've “unrolled the 
loop” (as discussed in chapter 12) when drawing the white square. Although it 
would be easier, and more compact, to draw the square with yet another pair of 
nested for loops (one to iterate across the squares width and one to iterate along 
its height), it's a bit faster simply to draw the wall square with a series of 
assignment statements placing the proper pixel values in all 16 of the video 
memory locations that constitute the 4 by 4-pixel square. 

The position of the player within the map should also be depicted in the 
automap. This is performed by the function drewplayer() 


void drawplayer(char far *sereen) 

{ 
unsigned int ptr=MAPY*3204+xview/64*1280+MAPK+yview/O4*6 > 
screenLptr J=PLAYER_COLOR; 
screenLptr+) J=PLAYER_COLOR; 
screenCptr+2J=PLAYER_COLOR; 
screenLptr+3 J=PLAYER_COLOR; 
screenLptr+320J=PLAYER_COLOR; 
screenCptr+321J=PLAYER_COLOR; 
screenLptr+322 J=PLAYER_COLOR; 
screenLptr+323J=PLAYER_COLOR; 
screenLptr+640 J=PLAYER_COLOR; 
screenLotr+641J=PLAYER_COLOR; 
screenLptr+é642 J=PLAYER_COLOR; 
screenLptr+643 J=PLAYER_COLOR; 
screenLptr+9460J=PLAVYER_COLOR;> 
screenCptr+961 J=PLAYER_COLOR; 
screenCptrt+962 J=PLAYER COLOR; 
screenLptr+963J=PLAYER_COLOR; 


Once again, this function only needs to know where video memory (or the 
screen buffer) is located. It then draws a 4 by 4 square in the PLAYER_COLOR 
to represent the position of the player within the maze, using the same sort of 
unrolled loop that we used to draw the wall squares. The location of the player 
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square is calculated using the MAPX and MAPY constant, plus the sxezew and 
yetew variables, which represent the current maze location of the player. (These 
variables are divided by 64 to determine which maze square the coordinates fall 
within.) 

We need to add one more function before our automap is complete. This 
function, which is identical to the drawpdayer function except in the choice of 
pixel color, will erase the image of the automapped player from the previous 
iteration of the animation: 
void eraseplayer(char far *screen) 

E 

unsigned int ptr=MAPY*320+xview/464*1280+MAPX+yview/64"4: 

screenCptrJ=0; 

screenCptr+lJ=0; 

screenLptr+e2J=0; 

ecreenLptr+3J=0; 

screenCptr+320I=0; 

screenLptr+3e21J=0; 

screenLptrt32¢J=0; 

screenLotr+s23J=0; 

screenlptr+é640I)=0; 

screenlptr+641 J=0; 

screenLptr+6421=0; 

écreenLptr+643J=0; 

screenLptr+9460I)=0; 

screenCptr+941 J=0; 

screenlptr+9ée2J=0; 

screenlptr+9631=0; 


And thats all We need Ci} do to create an AUTOM Ap. This code can then be 
called from the #earn() function. 


Tracking the Player 
In many games, the automap includes an additional feature. It shows where the 
player has been. Initially, the autcomap in such games is blank, but the squares of 
the map are gradually filled in as the player discovers them. This puts an 
emphasis on exploration, offering the player the exciting experience of 
“discovering” the maze as he or she wanders through ir. It also gives the player 
guidance by pointing out which parts of the maze have not yet been explored. 
Without this kind of guidance, the player may spend much of the game 
wandering in circles, which can be a frustrating experience (and wont necessarily 
endear your game to the player). 

How would you add such a feature to our demo? It wouldnt be difheult. 
Create a visibility array — that is, an array of integers in which each element 
corresponds to a maze square. (We've already set up several similar arrays in the 
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demo.) Initialize every element to 0. Then, as the player moves, set those 
elements corresponding to the square in which the player is standing, and the 
squares immediately adjoining it, to 1, When drawing the automap, only draw 
those squares that have been set to 1 in this array; all other squares should be 
black (or some other color indicating that they have not yet been explored). 

Of course, this is not an entirely realistic method of representing the player's 
exploration of the maze. Most of us can see farther into the distance than the 
equivalent of a few maze squares. If you're feeling ambitious, you might want to 
show all squares through which the player's visual rays have been cast. This would 
require making the visibility array accessible to the ray-casting engine and 
marking all squares through which a ray has been cast as having been seen. 


Playing the Game 

That's it. We've created the framework for a ray-cast arcade game. To play the 
game, go to the directory called GAME on the distribution disk and type 
GARDENS. First youll see the three ttle screens, [hen we fade up on the main 
game screen, with a red border created using Fractal Design's Painter, an 
extremely useful program for generating incidental game graphics. (The title 
screen was also created in Painter.) The border is loaded in the module 
GARDENS.CPE, using the same code that loaded the background for the demo 
in the last chapter. (See Figure 13-7 for a look at the border.) 
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Figure 13-7 The main screen of program GARDENS. EXE 





549. 


' 
(a = 4 





GARDENS OF IMAGINATION 


You can now move around through the maze, just as you did in the last 
chapter. The difference is that there are now objects in the maze, you can no 
longer walk through walls (because we check to see if the viewer is about to enter 
a maze square containing a wall block before allowing forward movement), the 
automap on the right side of the screen monitors your every movement, and 
there are objects at intervals throughout the maze, including cylindrical columns 
descending from ceiling to floor and floating skulls. 

You are encouraged not only to péay this game but to play wrth it: Expand it, 
improve it, and make it into an altogether viable commercial game. I've given 
you the tools to do so, now do it. 

You may find that it’s as much fun to create a maze game as it is to play one! 
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OT those of LL whose artistic talents have ncver developed much 
past the doodling stage, the creation of graphics can represent a 
serious stumbling block in putting together a computer game. 
Plenty of artists are willing to contribute their work for a fee, but 
if youre working on a tight budget that's only a small 
consolation. Fortunately, its possible to construct striking images on a 
microcomputer even without notable artistic talent — if youve got the right 
software, 

Some of that software is so expensive that youd be better off hiring the artist. 
But not all graphics software costs the proverbial arm and a leg, Some of the best 
graphics creation software is free. 

The three-dimensional maze images used in the BITMAZE program in 
chapter 4 were created entirely with freeware graphics utilities. | don't have room 
to include those utilities on the disk that comes with this book, but they can be 
obtained on most online services and quite a few local BBSes, as well as from 
computer user groups. And The Waite Group has published several book/disk 
combinations around these software packages. In the pages that follow, I'll 
describe how | created the images and show you how to create new images of 
YOU Own. 
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POVRAY 


The most exciting of these software packages in the Persistence of Vision 
Raytracer, usually called POWRAY for short. As you may recall from chapter 8, a 
ray tracer is a program that models scenes using mathematical descriptions of 
objects and light sources, and renders those scenes by tracing the path of 
imaginary rays of light from the viewers eyes into the display. Most ray tracers 
can produce stunning images, and the images created by POWRAY can stand 
alongside the best of them, POVRAY was created by a team of programmers who 
can usually be found hanging around the Graphics Developers Forum 
(GRAPHDEYV) on the C penpe ere Information Service. Fortunately for the rest 
of us, these programmers arent asking for any money from the users of 
POWRAY. The program is absolutely free. 

All of the images in the BITMAZE program (with the exception of the on- 
screen compass) were rendered with POVRAY. To create an image with 
POVRAY, you first need to create an ASCII text hile containing a description of 
the image using POVRAY’s built-in descriptor language. The descriptor fles used 
to create the BITMAZE images can be found in the BITMAP directory on the 
accompanying disk. There are ten of them, all with names ending in the file 
extension .POV. An example of one of these files, called TESTMAZE.POV, 
appears in Listing A-1. 





Listing A-1 TESTMAZE.POV 


if MAZE.POV 


Hinclude “colors.inc" 
Hinclude “textures.inc” 
Finclude “stones.ine” 
Finclude “maze. inc’ 


fdeclare MazeCube= 
object 
box { <-1 0 -1><1 2 1> 1} 
texture { 
WallTexture 
scale WallTextureScale 
ambient AmbientLevel 
} 
} 


ff A camera pointed down an aisle of the maze 





Camera 


i 


Location <0 1 -2> 
Look_at<0 1 3> 


} 


object 
object 
object 
object 
object 
object 
object 
object 


{MazeCube 
{MazeCube 
{MazeCube 
{(MazeCube 
{MazeCube 
{MazeCube 
{MazeCube 
{MazeCube 


translate 
translate 
translate 
translate 
translate 
translate 
translate 
translate 


<=? 0 2>} 
<-2 0 4>] 
<-2 0 &>} 
<0 0 10>} 
<2 0 O>} 
<7? 0 72>) 
<2? 0 46>) 
<- 0 8>} 


APPENDIA A 


ff The floor 
object { 
plane {<0 1 O O} 
texture f 
FloorTexture 
ambient AmbientLevel 
phong 7 
scale FloorTextureScale 
reflection FloorReflection 
} 
} 


ff The ceiling 
object f{ 
plane {<0 1 O> 2} 
texture f 
CeilingTexture 
scale CeilingTextureScale 
ambient CeilingAmbientLevel 
} 
} 


object f 
Light_source { <0 1 -2> color White} 
} 


It's not necessary to understand every line of this “program” to see what It 
does. Basically, it creates a series of texture-mapped blocks, distributes them at 
intervals on a texture-mapped reflective floor, throws some light on the scene, 
and renders it from the viewpoint of an imaginary camera. If you're curious to 
know exactly how this is done, you should locate a copy of the POVRAY 
documentation (or buy a copy of The Waite Groups Ray Tracing Creations) and 
read abour the descriptor language. 

For our purposes, the most important part of the descriptor file is at the 
beginning. Youll notice that the fle begins by including several additional files, 
exactly as weve been doing at the beginning of our C++ programs. These hles 
become part of the descriptor file, extending its capabilities. The first three 
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include files are standard POWRAY files and are distributed as part of the 
POWRAY package in the same way that include files like STDIO.H are 
distributed with every C/C++ compiler. The fourth include file, MAZE.INC, is 
one that | wrote. Actually, it's one of several files, all of which can bear the name 
MLAZE.INC at some point in the rendering process. I'll explain that further in a 
moment. In the meantime, check our the sample MAZE.INC file in Listing A-2, 





Listing A-2 MAZE.INC 


Rdeclare AmbientLevel=.45 

Hdeclare WallTexture=texture{Stonel& phong .1 turbulence 1} 
Adeclare WallTextureScale=<.75 .75 .f5> 

Hdeclare FloorTexture=texture{checker color Copper color White} 
Rdeclare FloorTextureScale=<.5 .5 .5> 

Rdeclare FloorReflection=.14 

Adeclare CeilingTexture=texture{Bright_Blue_Sky} 

Adeclare CeilingTextureScale=<1 1 1> 

Adeclare CeilingAmbientLevel=1.0 


As you can see, the MAZE.INC file is nothing more than a series of #declare 
statements. These work in POWRAY much as #declare statements work in 
C/C++ — that ts, they declare a string of ASCII characters to be equivalent to a 
different string of characters. When the program is parsed (thar is, read by the ray 
tracer), the first string is replaced by the second wherever it appears. This allows 
us to use meaningful terms such as WallTexture in place of such relatively 
incomprehensible expressions as texture(Stone]8 phong .1 turbulence 1), And, if 
you ll glance back up at Listing A-1, you'll see that all of the terms defined in the 
MAZE.INC file are used in TESTMAZE,POV. 

Why not just put the list of #declared terms in TESTMAZE.POV itself? 
Because keeping them in a separate file allows us to create new and very different 
looking mazes simply by creating new MAZE,INC files, or by editing old ones. 
There's no need to produce new versions of TESTMAZE.POV. If youll look in 
the BITMAP directory, you'll see that there are several files with the extension 
.MAZ, such as GREEN.MAZ, ICE.MAZ, APOCALYPMAZ, and so forth. 
These are MAZE.INC files tn disguise. They cant be called MAZE.INC because 
there can only be one file of that name in the directory. But, by the simple 
expedient of typing COPY ICE.MAZ MAZE.INC, anyone of them can become 
the MAZE.INC file, I've included a batch file that will do just that, along with 
invoking POWRAY to render the maze described by that file. 
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Building a Maze 


So how do you build your own set of maze graphics? First, get a copy of 
POVRAY, if you don't have one already. (The files in the BITMAP directory are 
intended for POVRAY 1.0, which has been superseded by POVRAY 2.0. If you 
want to use them with 2.0, youll need to make some modifications to the batch 
hles in this directory, as youll see momentarily.) Once POVRAY is on your disk, 
youll need to set it up properly for your system. That means you'll have to 
include the name of your POVRAY directory in the path statement in your 
AUTOEXEC.BAT fle. And you need to configure POWVRAY for your system by 
creating an environmental variable called POVRAYOPT. This variable will tell 
POVRAY, among other things, what kind of video adapter youre using. 
Instructions for doing this are in the POVRAY documentation. Be sure that the 
main POWRAY executable file is called POWRAY.EXE. 

Youll also need to hnd a program called PICLAB. Like POVRAY, PICLAB is 
free and widely available from online services, BBSs, and user groups. You can 
also find it on the disk included with The Waite Groups book /mage Lab, along 
with a stripped-down version of POVRAY. (Unfortunately, the version of 
POVRAY in Jmage fab lacks one of the standard include files that you'll need.) 
Place PICLAB somewhere in your DOS path, making sure to give it the name 
PL.EXE. 

Once POVRAY and PICLAB are in place, the rest is easy. Go to the BITMAP 
directory and type: 


PREVIEW ICE 

This executes a batch file called PREVIEW.BAT, which will render a single image 
of the maze described by the #defined constants in the file ICE.MAZ. To see how 
it does this, look at the text of PREVIEW.BAT in Listing A-3. 





Me Listing A-3 PREVIEW.BAT 


copy £1.MazZ maze.ine 

povray *+itestmaze.pov totestmaze.tga -wlsé@ -hl20 -p 
pl makemap testmaze 

pl maketga testmaze 

tgashow testmaze.tga 


First, the batch file copies ICE.MAZ (or whatever .MAZ file you indicated 
when you typed PREVIEW) to MAZE.INC. Then it calls POWRAY to read the 
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hle TESTMAZE.POV (which you saw in Listing A-1) and creates a rendered 
image in Targa 24-bit format called TESTMAZE.TGA. This image will have a 
width of 188 pixels and a height of 120 pixels. The -p switch tells POVRAY not 
to pause after rendering the image. If youre using POVRAY 2.0 or later, you'll 
need to add the +MV1.0 switch immediately after the -p switch. This tells 
POVRAY 2.0 to accept a POVRAY1.0 hile. 

We cant use a 24-bit larga hle in a mode 13h program, so we'll have to 
convert it to an 8-bit Targa fle. The batch file calls PICLAB to do this. For 
reasons that I'll explain later, this is done with two commands, PL. MAKEMAP 
TESTMAZE and PL MAKETGA TESTMAZE. The frst invokes PICLAB and 
tells it to read a fle called MAKEMAP This is a PICLAB batch file, which 
contains a set of commands for POVRAY to execute tn its batch mode. The text 
of the MAKEMAP file appears in Listing A-4. The commands in the fie tell 
PICLAB to create a 256-color palette for the TESTMAZE image and save it to 
che disk under the name MAZE.MAP. The next command, PL MAKETGA 
TESTMAZE, causes PICLAB to execure the commands in the MAKETGA 
batch file (shown in Listing A-5), which tells PICLAB to translate the 
TESTMAZE image to the 256-color palette created by the previous command 
and save it back to the disk under its original name, TESTMAZE. TGA. 


a Listing A-4 MAKEMAP 


set fileformat “TARGA” 
tload X1.tga 

makepal 

psave maze.map 








Listing A-5 MAKETGA 


set fileformat TARGA 
load *1.tga 
pload maze.map 
map 
save 41.tga 
Finally, che batch file calls the TGASHOW utility that we created back in 
chapter 4 to display the 256-color image. Congratulations! You've now created a 
single view of a maze. 
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OF course, that’s not the same thing as creating a set of maze graphics that you 
can animate with the BITMAZE program. But now that you've seen what the 
ICE.MAZ graphics look like using the PREVIEW batch hile, you're ready to 
render the entire graphic set with the MAKEMAZE batch file. The MAKEMAZE 
batch file, which is in Listing A-G, does much the same sort of thing that the 
PREVIEW batch fle does; tt just does more of it. It can be invoked by typing 
MAKEMAZE ICE at the DOS prompt in the BITMAP directory. 





| Listing A-6 MAKEMAZE.BAT 


copy 21.maz maze.ine 

povray +ifrontl.pov tofrontl.tga -wl88 -h120 <p 
povray tifront2.pov tofront2.tga -wi8& -hiz0 -p 
povray +ifront3.pov tofront3.tga -wl8e -h120 -p 
povray +ifront4.pov tofront4.tga -wl88 -h120 <p 
povray tifront5.pov tofrontS.tga -wi88 -h120 -p 
povray +isidel.pov +tosidel.tga -wi8a@ -—h120 -p 
povray +iside2.pov +osidez.tga -w188 -hi20 <p 
povray +tiside3.pov toside3.tga -wi88 -hi20 -p 
povray +iside4.pov toside4.tga —-wi8@ -h120 —-p 
pl makemap side’ 

pl maketga frontl 

pl maketga fronted 

ol maketga front3 

pl maketga front4 

pl maketga fronts 

pl maketga side’ 

pl maketga sided 

pl maketga sideS 

pl maketga sides 


Once again, you'll have to edit the batch file by adding the +MV1.0 switch 
after the -p switch in each of the nine lines that call POVRAY. 

As before, the batch file copies ICE.MAZ (or whatever) to MAZE.INC and 
then calls POVRAY. However, this time it calls POWRAY nine times, to create 
the files FRONTI.TGA through FRONTS.TGA and SIDEI.TGA through 
SIDE4.TGA. You may recall from chapter 4 that these are the nine image hles 
that the BITMAZE program slices and dices to create the animated image of the 
maze. The first hve show the fronts of the maze “wall cubes’ from hve different 
distances and the last four show the sides of the cubes from four different 
distances. You can view these files using the TGASHOW utility. The descriptors 
for these images are in the files FRONTI.POV through FRONTS.POV and 
SIDE1.POV through SIDE2.POV. The text of FRONT1.POV is shown in 
Listing A-7. As you can see, it looks pretty much like TESTMAZE.POV; it even 
includes the same files, MAZE.INC in particular, at the beginning. 
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= Listing A-7 


/f FRONT].POV 


Hinclude “colors.inc™ 
Ainclude “textures.inc™ 
finclude “stones.inc” 
Finclude “mare.inc’ 


Adeclare ZTRANS=2 
Hdeclare MazeCube= 
object ¢ 
box { «<1 0 =<T><1 2 1>-3 
texture f{ 
WallTexture 
scale WallTextureScale 
ambient AmbientLeve | 
} 
} 


// A camera pointed down an aisle of the maze 
camera ¢ 

Location <Q 1 -2> 

Look at<0 1 43> 
} 


object {MazeCube translate <-2 0 ZTRANS>} 
object {HazeCube translate <0 0 2TRANS>} 
object {MazeCube translate <2 0 ZTRANS>} 


// The floor 
object f 
plane {<0 1 O 0} 
texture { 
FloorTexture 
ambient AmbientLevel 
phong 1 
scale FloorTextureScale 
reflection FloorReflection 


tal 


ff The ceiling 
object tf 
plane {<0 1 O> 2} 
texture { 
CeilingTexture 
scale CeilinglTexturesScale 
ambient 1 
} 


a 
| 


1g 
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} 


object 7 
Light_source { <0 1 -2> color White} 
} 


(Be warned that the process of creating a complete set of graphics files with 
POVRAY can be time consuming, especially if youre using an older machine. 
On my 40MH¥Z 80486 machine, the process takes about 15 minutes, bur on 
older machines it will take longer. [f you have a newer machine, on the other 
hand, the process will be faster.) 

Once the 24-bit images are rendered, the batch file calls PICLAB to create a 
256-color palette for them. It then calls PICLAB nine more times to convert all 
of the images to that palette. That's why the palette creation is a separate step. It 
allows all images to be mapped to the same palette, a necessity if were going to 
be slicing and dicing them onto a single 256-color mode 13h display. 

Now you can run BITMAZE and see what it looks like with the ICE.MA/ 
eraphics, If you want to convert it back to its original graphics set, type 
MAKEMAZE GREEN. And if you want to explore the additional graphics sets 
ve included in the form of .MAZ files, just type MAKEMAZE <name>, where 
<name> is the name of the .MAZ file minus the .MAZ extension. Before you 
create a set of maze graphics, though, you might want to preview the .MAZ file 
by typing PREVIEW <names, to see if you like it first. 

Feel free to use these .MAZ files as templates for your own mazes. Load one of 
them into an editor, change some of the definitions, and save it to the disk under 
anew name (though you must remember to give it the .MAZ extension). OF 
course, this will require that you have at least a smidgeon of knowledge of the 
POV descriptor language, something | dont have space to go into here. Burt dont 
let that daunt you. Writing POY descriptors is simpler than you might think. 
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any otherwise competent programmers find assembly language 
baffling and intimidating. While it isnt necessary to master an 
assembler in order to write commercial game programs, a small 
knowledge of the subject would be useful in understanding some 
of the brief assembly language procedures in this book. This 
appendix wont teach you to write assembly language code, but hopefully ir will 





give you a sufficient grasp of the subject to understand such code when you see it. 

An assembly language program is written using two kinds of instructions: 
assembly language instructions and assembler directives. Assembly language 
instructions represent actual machine language codes that can be executed by 
the CPU after they are translated by a program called an assembler. Directives give 
the assembler important information about how it is to process the rest of the 
program, 

Few programs are written entirely in assembly language, Burt it is quite 
common to write small assembly language modules to be included with a C++ 
program. These modules consist of a few assembly language procedures, or 
PROCs, which play roughly the same role as C++ functions. In fact, if properly 
written, these PROCs can be called from C++ exactly as though they were C++ 
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functions. A PROC begins with the name of the procedure followed by the 
assembler directive PROC, like this: 


AsmFunction PROC 


And it must end with the name of the procedure followed by the assembler 
directive ENDP like this: 


AsmFunctian ENDP 


Berween the PROC and ENDP directives you place a series of assembly 
language instructions, each of which occupies a single line of the assembly 
language source file. These instructions alternate with occasional assembler 
directives — the names of which are usually written in uppercase letrers — and 
with comments, which must be preceded by a semicolon {:). (The semicolon in 
an assembler works exactly like the double slash (//) in C++, causing the 
assembler to ignore everything until the next carriage return.) 

Each instruction consists of a mnemwnic, which represents a CPU operation, 
followed optionally by one or more operands indicating what memory locations 
are to be operated upon. The mnemonic is usually a three-to-six-letter word, 
such as MOV or PUSH or ADD. Here's a typical assembly language instruction, 


followed by a COMMENT: 


add ax,Llengthl] ; Add AX and LENGTH, Leaving sum in Ax 


Most of the assembly language instructions in the PROC will concern 
themselves with moving numeric values around in the computers memory and 
performing mathematical and logical operations on those values. Often, these 
instructions reference a special set of memory locations situated in the computer 
CPU itself, These memory locations, known as the CPU registers, can be 
considered a set of permanent integer variables, The registers we will be concerned 
with are named AX, BX, CX, DX, SI, DI, BP SP ES, D5, CS, and SS. Four of 
these registers — AX, BX, CX, and DX — can be broken in pwo and treated as 
pairs of 8-bir variables. AX becomes AH and AL (with AH the high-byte of AX 
and AL the low-byte), BX becomes BH and BL, CX becomes CH and CL, and 
DX becomes DH and DL. The CPU registers are diagrammed in Figure B-1. 


Assembly Language Pointers 


Most of the CPU registers can be used for performing general arithmetic 
operations, such as addition and subtraction, and some of the 16-bit registers can 
be used as pointers to locations elsewhere in the computers memory. Just as 


566 





APDENDIA 6 





Figure B-1 Major CPU registers 


preceding the name of a pointer variable in C++ with the indirection operator (*) 
indicates that we are referencing the memory location to which that pointer is 
pointing, so surrounding the name of a CPU register with square brackets ([ ]) 
indicates that we are referencing the memory location to which that register is 
pointing, like this: 


tox] 


Actually, we will need to use nee CPU registers to point to a memory location, 
with one register holding the segment portion of the address and another holding 
the offset portion. The segment portion must always be placed in a segment 
register, usually either DS or ES. You include the name of this register in brackets 
with the name of the register holding the offset, like this: 


Les:dx] 

When the segment is in DS, however, its name does not have to be explicitly 
mentioned in brackets, since the CPU uses the segment in DS by default for all 
data references, 
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Getting It into a Register 


How do you place a value in a CPU register? In C++, you would use the 
assignment operator (=), but this does not exist in assembly language. Instead, 
you must copy the value from another memory location or CPU register by using 
the MOV instruction (which should really be ‘called the COPY instruction), like 
this: 


mov ax,Ces:dx] 


This copies to the AX register the value stored in the memory location pointed to 
by [es:ds], We can also identify memory locations by their addresses, though it is 
more common to name those addresses and then identify the locations by name. 
For the moment, | wont discuss rechniques for assigning names to locations, but 
you would refer to a named location like this: 


mov ¢x,Ssize 


where size is a name that we ve assigned to a 16-bit memory location. 

Values can be copied not only from memory locations, but from other 
registers and even from the instruction itself. A value copied from an instruction 
is called an fmmediate value and is referenced like this: 


mov dx,1040h 


This copies the value 1040h (the “h’ indicates that the value is in hexadecimal) from 
the instruction into the DX register. 

When using assembly language pointers, it is sometimes necessary to specify 
what sort of value the pointer is pointing at. The three types of values recognized 
by 80x86-series CPUs are BYTEs (8-bit values), WORDs (16-bit values), and 
DWORDs (Double WORDs, or 32-bir values). Thus, a pointer 1s either a BYTE 
PTR, which points ata BYTE value; a WORD PTR, which points at a WORD 
value; ora DWORD PTR, which points at a DWORD value. For instance, these 
instructions copy a WORD value from the address pointed to by es:bx to the AX 
register: 


mov ax,word ptr Ces:bxJ 


OF course, the assembler can also figure out that [es:bx] must be a word pointer 
because you want to move the value stored there into a 16-bit register. But there 
will be instances when the size of the value is less obvious. And it doesnt hurt to 
make it explicit anyway, if only to make your code clear to somebody else reading 
IE. 

There are special assembly language instructions for putting pointers into 
registers, An assembly language pointer actually stretches across two registers, 
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with either ES or DS holding the segment part of the pointer and another 
16-bit register holding the offset. Does this mean that we must use two MOV 
instructions to get the pointer into these two registers? Fortunately not. The 
80x86 instruction set (that is, the set of instructions that can be executed by 
CPUs in the 80x86 series) includes special instructions for loading pointers into a 
pair of registers. The two instructions that will be used in the programs in this 
book are LDS and LES. The first loads a segment into the DS register and an 
offset into a second register. The other does the same with the ES register. For 
instance, if we wished to load the pointer stored at the address weve named 
old_pointer into the es:dx registers, we could write 


les ds,old_pointer 


Assembly Language Odds and Ends 


Before you can use certain registers in a PROC that is to interface with C++ 
code, you Must save the value stored in those registers IN a section ot memory 


called the stack. This is done by using the PUSH instruction, like this: 
push ds 
push di 
push s7 
Then, before the program ends, these values must be restored to the original 
registers, in reverse order, by using the POP instruction, like this: 
pop 51 
pop di 
pop ds 

Some assembly language instructions have an effect on the CPU fags. These 
are simply isolated bits within a special register, which reflect the results of 
instructions. For instance, if the result of a subtraction instruction (SUB) is 
zero, the zere flag will be set (given a value of one). What good does this do you? 
You can give other 80x86 instructions contingent on the way in which the Hags 
are set. [hese instructions usually cause the CPU to begin executing instructions 
at a different address in memory if the Hags have a particular setting. Thus, they 
can be used to simulate high-level IF and WHILE instructions, by skipping some 
instructions and executing others based on the outcome of other operations or 
repeating a set of instructions in a loop if the flags are set in a certain way, 
Commonly, these operations are preceded by a comparison instruction (CMF), 
which checks to see if two values are equal or are unequal in a certain way. For 
instance, the instruction cmp ax,dx would compare the values in the AX and DX 
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registers. This could then be followed by a j= instruction, which would cause the 
processor to “jump to a new address if the zero flag is set — thar is, if the values 
in AX and DX are equal. This is equivalent to the C++ instruction: if (ax==dx). 

Perhaps the fanciest of these “conditional jump” instructions is LOOP, which 
subtracts one from (decrements) the value in the CX register and jumps to a 
certain address if CX doesn't then equal zero. Variations on this instruction, such 
as LOOPWNE and LOOPY, can be made to check the value of a Hag and 
terminate the loop when a certain Hag setting is detected, even if CX has not yer 
been decremented all the way to zero. These instructions can be used to produce 
structures similar to the high-level WHILE and FOR loops. 

Occasionally, assembly language procedures must call other procedures, the 
way that C++ functions call other functions. This is done via the CALL 
instruction, which must be followed by the name of the procedure being called, 
like this: 


call other_procedure 


The assembler translates the name of the procedure being called into the actual 
address at which the code for that procedure resides in memory. 

Finally, every assembly language procedure must end with a RET instruction 
and the ENDP directive. Although ENDP tells the assembler that the procedure 
is over, the RET instruction causes the CPU to return control of the program to 
C++ when the assembly language procedure is complete. The RET instruction ts 
equivalent to the C++ return instruction, as well as to the final curly bracket (}) at 
the end of a C++ function. 

There is a great deal more to know about assembly language, and we can only 
scratch the surface in this book. To avoid confusion, I'll explain the few relevant 
assembly language concepts as they arise, For now, we will mention only one 
more: how ce) Pass parameters from C++ ta an assembler. 


Passing Parameters to 

Assembly Language Procedures 

In C++, you can pass parameters to a function by placing the values of those 
parameters in parentheses after the function call, like this: 

get_lost(23, "“skidoo"); 


You'll pass parameters to assembly language procedures in exactly the same 
way. But how does the assembly language function recetve the parameters? In 
C++, you would simply write a parameter list in the function header, specifying 
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the types of the parameters and the names by which you wished to refer to them. 
In an assembler, its not quite that easy. When the assembler procedure begins, 
the parameters will be in the stack. To fetch the parameters from the stack, you 
need to know exactly how C++ organizes those parameters on the stack. Bur 
Turbo Assembler (and most other Microsoft-compatible assemblers for IBM- 
compatible computers) provides a simple method of accessing parameters: the 
ARG directive. 

No, ARG isnt what you say when you stub your toe against your computer 
desk. It’s a directive that tells the assembler which parameters you expect to be 
passed from C++, the order in which those parameters will be passed, and the 
number of bytes that each parameter will occupy. In return, the assembler allows 
you to refer to those parameters by name rather than by their location on the 


stack. The ARG directive works like this: 


ARG first_param: BYTE, second_param:WORD, third_param:DWORD; 


This tells the assembler to expect three parameters — first_ param, seconal_panam, 
and third_param — to be passed to the procedure from C++. It also tells the 
assembler how much memory each of these parameters will occupy. The first will 
occupy one byte (as indicated by the word BYTE attached to the name of the 
parameter by a colon), the second ewo bytes (or one WORD), and the chird four 
bytes (or one DWORD), Other sizes can be specified, burt these are the only ones 
that we ll use in this book. 

Once the ARG directive has been placed at the beginning of the procedure, 
just after the PROC directive, you can refer to these parameters by name. The 
one catch is that the following pair of instructions must be included at the 
beginning of any procedure that uses the ARG directive: 
push bp 
may bp,sp 


Place these two instructions before any other PUSH instructions are executed. 
These instructions set up the BP register as a pointer to the stack area where the 
parameters are stored. The assembler will translate all references to these param- 
eters into pointers using the BP register. For this reason, you should never use the 
BP register in any procedure that has an ARG directive. 

Near the end of the procedure, after all other POP instructions have been 
executed, include the following instruction: 


pop bp 

This restores the BP register back to the value it was previously storing. (Most likely, 
the C++ function that called the assembly language procedure was aise using the BP 
register as a pointer to parameters stored on the stack, which ts why it is important 
that the value be returned intact at the end of the procedure.) 
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Is it possible tor an assembly language procedure to return a value the way that 
a C++ function can? Sure it is. An assembly language procedure can do anything 
that a C++ funetion can (and occasionally a bit more). The way in which a value 
is returned from an assembly language procedure depends on what type of value 
it is. For instance, values of type int (or any other 16-bit values) are returned in 
the AX register: The value must be placed in the AX register before the procedure 


terminates. Larger and smaller values are returned using simular techniques. 
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ambient light, 269, 419, 517 

ANDing, 301, 304-305, 328 

animation, 14, 240, 325, 461, 466 
inimarion engine, 4-10 

animation, and heightmapping, 397-398 
animation, and lightmapping, 458 
animation, maze,’ -103 

ARG directive, 22, 81 

arpument parameters, 117-118, 322 
assembly language, 17, 22, 563-570 
assembly language translation, 461-462, 519 
automap, 546-548 

automap( ) function, 547 


B 


backpround color, 269 
background images, 218 





banding, 285,431 

Bard's Tale games, 5 

be (background) [MCX structure, 150 

binary numbering, 468, 47 1 

bicmap defined, 108 

bicmap scaling, 196-206 

bitmap storage, 108-109 

biomapped drawmaze! | function, 140-144 

birmapped maze, building, 129-157 

bitmapped mazes, 12-13 

BITMAZE program, 149-157 

BITSCALE-CPP, 202-206 

blitt ) function, 151-152, 158 

block-aligned heightmaps, 360-37 | 

block-aligned lightmaps, 433 

BLOKCASTACPP, 363, 371-477 

BLOKDEMO.CPY, 378-381] 

Borland (we, 17 

Borland Graphics Interface (BGT), 17, 32 

botditt, 176 

boterror, 177 

bottom! | array, 186 

bounds checking, #46, 364 

break code, “(+72 

break instrucnion, 33 

Bresenham 5 Algorithm, 40, 43-46, 173, 177, 
209 

brightness, 401-404, 40-407, 419 

bubble sort, 935-536 


C 


calculations, march, 464-465 
Cartesian coordinare system, 32-33, 241, 250, 
3) 
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Cartesian plane, 232-234 
(Cartesian units (units of measure), 241 
ceill) function, 285 
ceiline| | array, 338-339, 344, 347 
ceilingcasting, 338, 343-344 
ceilinglites| | array, 433-434, 458 
ceilings, optimized, 489-497 
circular system, 248 
clipping wall, 369 
CLER_TCK macro, 08 
clock() function, 98 
drscr() function, 83 
(cLS (clear screen} procedure, 31-352 
CMP instruction, 71 
color (palette), 27-30, 268-269 
color brightness, 407 
color and light, 262-264 
color map, 111-112, 114-115 
column angle, 308 
column clipping, 328-330 
COLUMNLOOP macro, 487, 489 
comments (; and), 24, 20, 364 
compass, 248 
compass MCX structure, 150 
compass_face array, 150, 153 
components, vector, 247 
compressing data, 10%, 121, 159 
computer role-playing games (CRPG), 4 
continuous (smooch) monon, 7, 325 
coordinate pair, 32 
coordinate systems 
Cartesian, 32-33, 241, 250, 299 
fine, 300-301, 311 
polar, 247-258 
cosine adjustment, 315-316, 342 
cosine/sine, 254-256, 476-478 
CPU flags, 567 
(PU registers, 304-307 
credirs, opening, 541-546 


D 

decimal numbering, 468, 470 
delete function, 133 

depth sort, 535-536 
dereferencing, 20 


direction vectors, 241-247, 250-252 
discriminant, 278, 283 
display_slice( ) function, 146 
distance| | array, 527-528 
dithering, 285 
divide-by-0 error, 273, 284, 304, 312, 405 
division (/) operator, 29 
Doom, 9-10, 359-360, 396-397 
draw_maze( ) hinction, See ate drawmazel } 
function 
block-aligned heightmapped, 371-377 
Hoorcasting, 44-346 
Hoorcasting, wallcasting, 348-354 
lightmapped, 434-440 
lightsourced, 423-44) 
optimized, 500-508 
texture-mapped ray-cast, 332-336 
tiled heightmapped, 389-392 
tiled lightmapping, 446-453 
wallcasting, 306-321 
draw_slicel ) function, 149 
drawbel } function, 218 
drawbox{ } function, 0, 184 
drawceilrow! ) function, 441, 499 
drawHoorrow! ) function, 491, 498 
drawmazel ) funetion, 99. See abe draw mazet | 
furicrien 
birmapped maze, 140-149 
polygon mane, 185-190 
wireframe 31) maze, 48-58 
drawobject( ) function, 537-339 
drawplayer( ) function, 547 
drawwall( ) function, 484-488 
Dungeon Master, 6, 76 
DW (Dehine Word) directive, G7 


E 
EMPTY.TGA file, 218 

endpoints, 36-37 

eraseplayer( ) function, 548 

error code, 81-82, 113, 117-118, 124 
error message, 414 

error term, 43, 178-179, 330-332 

error terms, 173, 177, 199-201, 210-212 
escape chase, 74 





event manager, 1-97 

evene structure, 92-93, 98 

events, maze, 92-95 

exitl ) function, 118 

expanded memory (EMS), 159-160 
Eye of the Beholder, 7, 107 


c 
fabs( } function, 413 

held of view, 235 

hile formats, 109-110 

ne coordinate system, 300-301, 311 
hsh-eve effect, 315, 342 

fixdiv( ) function, 475-476 

fixed point math, 174, 312, 465-476, 519 
xed point trigonometry, 476-48] 
hxmull } function, 473-474 

Hicker, 100-101 

Hight simulators, 7-8, 231, 234, 239-240 
Hoating point math, 173-174 

Hoating point unit (fpu), 465-466 
Hoating point variables, 311 

Hoorl ) function, 285, 339, 342 
Avorbase[ | array, 384-385 

Hoorcasting, 298, 337-346 
FLOORDEM, 346 

Hoorheight changes, 365-371 
Hoorheight| | array, 341-364, 367 
Hloorheight| | array, tiled, 384 

Hoorlites| | array, 435-434, 454 
FLOORLOOP macro, 493, 499 

Hoors, optimized, 489-497 

Hoor[ | array, 342, 347 

Horl | array, 338-339, 342, 362-365 
Horl | array, tiled, 385-386 

fort } loop, 27 

for!) loops, nested, 29, 118, See ate loops, nested 
fractions, 468 

freeware, 553, 557 

function 25h, G7 

function 35h, 67 


G 


game features, 539-541 


Index 


gameport byte, 85-86 

Camiers Forum, xii, xvii 
GCARDENS.CPP, 549 

Get Interrupt Vector, 67 
petevent( } function, 5-7 
GIF formar, 109, 110-111 
CO) GAMERS, xii, xvi 
Gold Box games, 5 
GOMAZE program, 101-103 
goroxy( ) function, 83 

grabl ) function, 150-151, 158, 197 
GRAPHDEY forum, $44 
graphics utilities, 553 
gray-scale palette, 268 

grid lines, 144-145, 302 


H 


hardware, 462-466 

header files, 26 

height changes, Hoor, 365-371 

height tiles, 383-384 

height variable, 177 

height of viewer, 364-365 

heighteasting, 363-364, 386, 395-396 

heightmapped ceilings, 38 1 

heightmapping, 9, 354, 360 

heightmapping, animated, 397-398 

heightmapping engine, 386-389 

heightmapping, hybrid, 396-397 

heightmaps, block-aligned, 360-371 

heightmaps, pixel-aligned, 382 

heightmaps, tiled, 382-389 

hidden surface removal, 324, 382, 524-328, 535, 
949 

HIGHMAPS.PCX, 383 

HORALINE program, 38-39 

HTIMER rounnes, 50-510 


ih) starermend, 179, 200 
increment valuc, 485 

incremental division, 43, 196, 3450 
init_events( ) function, 93 
initkey{ | function, 67-69 
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initimouse( ) funcdon, 78-79, 81-82 
inline function, 479 

input devices, 63 

iInserman som, 535-5346 
installation, xix 

INT 21H routines, 67 

INT 33H instruction, 77 
interface types, 541 
INTErrUpt handler, 65-67, 69 
Interrupt, keyboard, 65 
inverse square law, 404-405 
IRET instruction, 69, 73 


J 


joystick, 84-91 

joystick buttons, 85-86 
joystick calibration, 89, 93-5 
joystick position, 86-88 
JOYSTICK program, 89-9] 
jump instruction, 71-72, 568 


K 


kbhit{ ) function, 27, 5-42 
kevboard, 63-76 
keybulfer array, 93, 96 
kilobyte, defined, 230 
Kirk, James T., 231 
kludge, 523-524 


L 


libraries of functions, 17, 64 

light, 402-404 

light and color, 262-264 

light intensity, 405-409, 419, 432 

light pool, 403, 404, 446 

lightmapping, 432-434 

lithemaps, block-aligned, 433 

lightmaps, tiled, 445-446 

lightmaps, using, 458 

lightsourcel ) function, 279-280, 282, 284-285 
lightsource! }[ ] array, 409, 414, 423 
lightsourced 31) graphics, 9 

lightsourcing, 1M 191, 226, 279, 401-404 
lightsourcing, alternate effects, 430-432 





lightsourcing formula, 405-414, 418 
lightsourcing tables, 40410, 417-419 
line drawing, 35-43 
line, honaental, 37-39 
line, vertical, 39-40 
linedrawt | function, 44-46 
lines, 37-43 
lines of arbitrary slope, 40-43 
listings 
bitmapped drawmaze( ) function, 147-149 
BITSCALE.CPP program, 202-206 
blit( ) function, 152 
block-aligned heightmapped draw_mazet ) 
function, 371-377 
BLOKDEMO.CPP, 378-381 
CLS (clear screen} procedure, 31-32 
draw_slice( } function, 144) 
drawHoorrow! ) function, 498 
drawal! ) function, 488 
hxdiv( } function, 476 
fixmull ) function, 4774 
Hoorcasting draw_mazet ) function, 


344-346 

Hoorcasting, walleasting draw _mazel | 
function, 348-354 

FRONT 1.POY, 560 


eetevent( | function, 96-97 

grabi ) function, 151 

HORALINE program, 38-34 

init_events( ) funceion, 93 

initkey( } function, G84 

initmeuse! )} funcoon, 79 

JOYSTICK.CPP program, 90-91 

lightmapped draw_miaze() function, 434- 
all 

lightsourced draw_maze( } hinction, 423- 
43) 

linedraw( } function, 44-46 

LITEDEMO.CPP program, 419-422 

load_image( ) function, 126-127 

load_palette{ } function, 127 

load MOM ) funcuon, 125 

load TGAL ) function, 115-117 

main! ) function from BITMAZE.CPP, 
14-157 





listings comstmued) 

main( ) function from GOMAZE.CPP, 
101-104 

MAKELITE.CPP program, 415-417 

MIAKEMADP, 438 

MAREMAZE BAT, 55% 

WIARE TGA, 558 

MARKETRIG.CPP, 481-485 

MAPDEMO.CPP program, 441-445 

MAZE.CPP program, 33-58 

MAZE ING, 556 

MOUSE.CPP program, 33-84 

newkey( ) function, 74 

OPTDEMO.CEP module, 510-517 

optimized draw_maze( } function, 501-508 

PALETTE.CPP program, 25-30 

MOA HEADER structure, 121 

PCX STRUCT stnacture, 122 

PCASHOW program, 128-129 

POLYCLIP program, 184-185 

POLYDEMO.CPP program, 183-184 

polydraw( } furiction, 180-182 

POLYGON.CPP, 165-166 

polygon-based drawmaze( ) function, 188- 
[SO 

polytexe( } hanction, 212-215 

portions of TRIG.CPP, 484 

PREVIEW .BAT, 557 

readibutton( ) function, 86 

readmbucton( | function, 79-80 

readstick( ) function, 87-88 

relpost ) function, #1 

remkey( ) function, 69 

RTDEMO-CPP program, 285-290 

SCANKEY.CPP program, 75 

seroenten } function, 94 

sctmaxl } function, 4-55 

setmint ) function, 94 

SETMODE procedure, 24 

SETPALETTE procedure, 28 

TESTMAZE.POYV, $54-555 

TEATDEMO.CPP program, 215-217 

TEXTMAZE.CPP program, 218-226 

texture-mapped ray-cast draw _magel ) 
function, 342-336 

tga_header structure, 111 


Index 


TGASHOW.CPP program, 119-120 
tiled heightmapped draw_mazel ) function, 
389-392 
tiled lightmapping draw _miaze/ } hanction, 
447-453 

TILEDEMO.CPP program, 392-396 
TLMDEMO.CPP program, 453-457 
TRIG.H hile, 483-484 
VERTLINE program, 39-40 
wallcasting draw_mazel ) function, 318-321 
WALLDEMOLC?P program, 323-324 
WHITEOUT.CPP program, 26 

LITEDEMO.CPP, 419-422, 430 

litelevel[ | array, 417-418, 423 

LITEMAP. CPP, 434-440 

load_image( ) function, 124-127 

load_palette( ) function, 124, 127-128 

loading Targa files, 112-117 

loadPCX( ) function, 124-125, 153, 326 

load TGAC ) function, 112-117, 153 

loop unrolling, 463-464, 519 

LOVOPNE instruction, 87 

loops, nested, 29, 118, 365, 411, 466-467 

low-resolution ray tracing, 268 

Iseeki | function, 113 


MI 
macro CLK_TCK, 98 

macro COLUMNLOOP, 487, 489 
macro FLOWORLOOP, 493, 499 
macro MBK_ PP, 20,27 

macros, 464, 478-479, 487, 519 
magnitude, 241, 243-248 

maint ) function, 26 

make code, 70-72 

MAKELITE.CPP, 410,.414-417, 431 
MAKETRIG.CPP, 481-483 
MAPDEMO.CPP, 441-445 

math, 173-174 

matnix| | array, 185-186 

mare animarnon, 7-103 

maze elements, 1A 

maze engine, refining, 158-160 

mage games, 4 


maze grid, 144-145, 298, 300-301 
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maze tounng, 157-158, Loo 
maze types, 12-14 

maze views, 131-133 
MAABACPP, 53-58 
mazre-drawing algorithm, 134-140 
megabyte, defined, 229-24) 
memory circuit, 18 

memory problems, 158-160 
messages to user, 410-414 
mickey (unit of measure), 78, 80 
MK Fi macro, 20, 27 

mode 13h, 21 

modulus operation, 29, 30] 
MONATGA, 196 

mouse, 6-84 

mouse driver, 77-79 


MOUSE program, 82-84 


N 

new function, 114 

newkev( } function, 67, 69-73 
normal vector, 244, 266 
normalizing, 252 

MOT instruction, 85 

number line, 230 


numbering systems, 18-19, 468 


O 


objdraw( } function, 328 

object array, 324, 328 

objects, drawing, 531-534 
objects, maze, 523-524 

objects, representing, 328-531 
objlist array, 534, 337 

olfser, array, 27 

offsers, 18-19 

opent ) function, 113 

operator precedence, 246 
OPTDEMO program, 508-517 
optic parallax, 234 

optumuizatvon review, 317-520) 
optimize, where 10, 466-467, 320 
origin, 35 


i at 
peas) 


| 


p 


paint programs, 108, 121, i635, 383 

Painters Algorithm, 535 

palette, 27 

PALETTE.CPP program, 29-30 

paltadeourt } function, 542 

parameterized form, 277 

PCX format, 109, 121-129 

PCX_ HEADER structure, 121 

PCA_STRUCT structure, 122 

PCXSHOW program, 128-129 

perrar( } function, 414 

perspective, 234-238, 316, 368 

perpective equation, +33 

Pickab, 110, 121, 198, 357 

pixel, 21, 35-36 

pixel, drawing, 201-202 

pixel, plotting, 33-35 

plane, defined, 229 

player, tracking, 348-349 

plor( ) function, 276, 285 

point-slope equacian, 174-175, 302-304, 
413-314 

pointers, 19-20 

points, 35-36 

polar coordinate system, 247-255 

POLYCLIP program, 184-185 

POLYDEMO program, 182-184 

polydraw{ | function, 171, 180-182, 186 

polygon clipping, 169-171, 173-174, 176 

polygon, filled, 166-168 

polygon graphics, 164 

polygon maze, building, 171-182 

polygon mazes, 12-13 

POLYGONS CPP program, 165-166 

polygon-drawing algonthm, 171-173 

polygon-hll graphics, 167, 238 

polygons, 164-168 

POLYMAZE.CPP program, 190-191 

POLYRAY ray oracer, 291 

polytext{ ) function, 208-215 

polytype structure, 16%, 171 

ports, inputting data, 70, 85 

POWRAY ray tracer, 108, 110, 121, 130-131, 
291, 554-556 





prev_t variable, 280, 282 

PROC (procedure) statement, 22-24 

processors, 462, 404-466, 470) 

prohler, 467, 520) 

per variable, 178 

putwindow( ) function, 101 

Pythagorean method, 245, 251, 275, 284, 
314-315, 533 


quadratic equation, 278, 283 


R 

radian system, 249 

radiacion (light), 402-404 

random number generator, 272 
random } function, 285 
randomurel ), 272 

ratio variable, 2099-210 

ray casting, 292, 297-298, 303-305, 311-313 
ray tracer, building, 264-280 

ray tracer, defined, 131 

Tay tracers, 291 

ray tracing explained, 262-264 

ray tracing a maze, 130-131 

ray-cast graphics, 258 

ray-cast mazes, 12-14, 324-325 
ray-casting algorithm, 28, 303-305 
ray-object comparisons, 276, 280, 295-296 
ray-wall comparisons, 304-305, 309 
RAYDEMO, 354 

rays, reducing, 296-297 

read( ) function, 111, 113-114 
readjbutton( ) function, 8, 88 
readmbuttant :) function, 78-80, 82-83 
readstick( ) function, 87-89 
realism, 26] 

recursion, 134, 139, 141 

recursive algorithm, 186 

recursive hinction, 134, 140 
reflected light, 262, 403 

reHective surfaces, 291 

resister, 23 

relpas( ) function, 78, 80-83 


Index 


remkey( ) function, 67, 69, 76 

ROM BIOS, 22-25 

roars (quadratic), 278, 283 

rotating birmaps, 1b 

rotating point, 254-257 

rotating ray, 309-311 

rotation equation, 310-411 

rotation, three-dimenstonal, 257-258 
RTDEMO.CPP program, 285-290 
mun-length encoxling, 122-123 


S 

scaling bitmaps, 196-206 

scan cde, 65, 70-72 

SCANKEY program, 74-75 
SCCREEM_LASM, 22 
screen-clearing, 30-32 

scpmicnits, |S 

semicolons, usc of, 24, 364 

Sct Interrupt Vector, G7 
set_palette| ) function, 118 
sercenter( } function, 93-4 
sctmax( } function, 93-5 

setmin( ) function, 93-94 
SETMODE procedure, 24 
scimade( ) function, 27 
SETPALETTE procedure, 28 
shadows, 269, 403, 419, 430 

shift operation, 301, 311, 471-473 
similar tangles method, 340-3435, 364, 388 
sincioosine, 254-256, 476-478 
sizeotl ) funcoon, 113 
slice-and-dice maze generation, 134, 163-164 
slope, 40-45, 174-175 

slope of ray, 312 

smooth movement, 7, 325 
smooth-scrolling arcade games, 10) 
Sort types, 945-556 

sphere, ray tracing, 282-284 

sqrt function, 246 

stack, 524, 567 

string instructions, 3] 

surface normal, 266 

swapping method, 535-536 
switch ) statement, 31, 281 
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T 


unit (unit of measure), 277, 283 
table look-ups, 404-465, 476-478, 519 
target hardware, 462 

TEXTCAST CPP, 352-336 
TEXTDEMO, 336 
TEXTDEMO,CPP, 215-217 
rextdemot ) function, 215 

TEA TMAZE CPP, 218-226 

rexture clipping, 209-21 | 


rexture mapping, 164, 191, 195, 206-208, 291, 


$26-436 
fexture-mapped mare, 218-226 
rexture-mapped polygon function, 208-215 
TGA (Targa) formar, 1 10-120 
tea_header structure, 111 
TGASHOW program, 117-120 
three-dimensional graphics, 226 
three-dimensional space, 231-234 
tick (unit of measure), 98 
dled heightmapping engine, 386-389 
tiled hetghtmaps, 382-389 
tiled lighomaps, 445-446 
TILEDEMO.CPP, 392-3% 
TLMDEMO.CPP, 453-457 
rmcolumn vanable, 328 
ropeliff, 176, 179 
toperror, 177, 179 
rop[ | array, 186 
trace_ray( } function, 276-285 
transtormarions, coordinate, 295-258 
transforming, 256 
translating point, 296 
triangles, similar, 340-343, 364, 388 
TRIG.CPP, 484 
TRIG.H file, 483-484 
trigonometry, 308-309, 465, 476-481, 519 
Turbo Assembler (TASM), 22 
Turbo Profiler (TPROF), 467, 520 
pwo-and-a-half dimensions, 238-241 
type override, 271] 





U 


Ulama games, 4-5 
underscore, use of, 22, 474 
inion structure, 265, 27] 
unit circle, 253-254 

unit vector, 252-754 


\V 
vector oomnpanertts, 247 
vector_cypet structure, 265 
vector_cype variables, 272 
vectors, direction, 241-247 
vectors, unit, 292-253 
vertex/ vertices, 164, 238 
VERTLINE program, 39-40 
VGA palerte, 27-30 

video display programming, 17 
video memory, 18, 24-27 
video mode setting, 22-24 
viewer height, 364-305 
Wiewer orientation, 48-49) 
viewer position, 48-49 
viewport, L69 

virtual realiry, 7-8, 523 
visibiliry array, 524, 548-549 
visibility variable, 51 

visible[ |{ | array,-527 
VIVID ray tracer, 21 


\W 

wall squares, 46-47 

walleasting, 298-300, 306-321 
WALLDEMO.CPP progeam, 321-325 
walls, optimized, 484-488 

wall[ | array, 347, 362-363 
walll | array, tiled, 385-386 
while( ) loop, 153-154 

while( } statement, 179, 200 
WHITEOQUT.CPP program, 26 
width variable, 176 

wireframe mazes, 4, 12, 32-59 
Wisardry games, 5, 107 
Wolfenstein 3D), 9-11, 337-338 
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THE BLACK ART OF 
WINDOWS GAME 
PROGRAMMING 


Erit R. Lyoms 

Microsoft's recently created 
toolkit, WinG (for Windows 
Lrames}, is aimed spectically at 
making Windows eames pérlonn 
a8 fast as DOS-based games— 
without sacnficing any of the 
benefits of Windows. With Wind 
und the Black Artiog Window's 
Game Progranunine YOU Ten 
Fame programmers heaven— 
your games will scream, That's 
what this book 14 about—yuickly 
getting up to speed on the 
Windows programming environ: 
ment and, specifically, taking 


advan of WinG to make fe 


high-perlorniie 2ames. 


Available Febroory 1995 
300 pages 

ISBN: 1-8/8739-95-6 
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FATAL DISTRACTIONS 
Dovid Gerrold 

These top PC shareware games 
on CD-ROM will give you the 
thrills and chills of an arcacdk in 
your home withoul the emburass- 
ment of having total strangers 
overhear your agonized cries-ot 
defeat and your ecstatic screams 
of victory. These games include 
classics and little known adven- 
ture, simulation, combat, arcade, 
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ea | 


ind dunecon eames, us well ws 
(for the adrenaline-challenged) 
table, word, carl, and mare 
Venues. 


Available now © 150 poges 
ISBN: 1-B78/99-77-8 
U.5. 526.95 Con, $37.95 
Disk: 1-CD-ROM 


MODELING THE DREAM 


Phil Shate 


More than 500 meeabyies:of the best computer 
animations on the planet, supported by exciting 
music, make fora package of truly mind-warping 
proportions. Take a dizeving nde through the 
insides of ain arcade came, ploting an attack hell- 
copter thraveh an urban landscape, and brearme 
andrdids fighting to the death. You'll alse go 
behind the scenes to share the secrets of these tal, 


ented antists and programmers, 


November 1994 © 150 pages, ISBN: 1-878739-67-0, US. $32.95 Con. $45.95, 
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Who says i takes-six chiys to 

create aoworkd! With the gutil- 
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simulation. In addition to these e 
technical details. the honk alse 
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mses Involved so that you can 4 
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tit and-exctling environments, + 
The package includes the larest 
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VR renderer REN D386, sample 
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ing the source code for adding 
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Available now * 350 poges 
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FLIGHTS OF FANTASY (ibaa 


Christopher Lampton 


Take gnin-depth, behind-the- 


scenes tour-of writing 3-D video 

eames with Borland C++, learn 

to build a complete, full-featured 
‘ fight simulator, modeled alter 


. the one included on the disk. 


Available now * 560 pages 
ISBN: 1-678739-18-2 
2) U5. $34.95 Con, $48.95 


Dicks: 13.5" 
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CREATE STEREOGRAMS 
ON YOUR PC 

Don Richardson 

Stereograms go beyond flat 2D 
it into a world of astonishing, 
upparcnily randam specks that 
suddenly collide in your Vision 
to create 3D hologram-hke ilu- 
srons. This book/disk package 
provides step-hy-siep (sire 


tions and all the araphics tools 


Bn) a needed ti create Your ain slene- 





_ ograms on any PC, 


fae Available now * 200 pages 
ye (SBN: 1-878739-75-1 

U.5. $26.95 Con, $37.95 
(1 - 3.5” disk) 
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WALKTHROUGHS 


AND FLYBYS CD 


GABYTES GF THE 
Se 5) SHeATED 
PRESENTATIONS 





PHIL SHATZ 





AND FLYBYS CD 

Phil Shotz 

This book/CD packape serves up 
aWe-INSping Animated computer 
demos, complete wilh sound and 


wSSAUd dNOUS ALIVM 


music, dnd a behind-the-scenes 
look wt thew creation. ie 


ISBN: 1-878739-40-9 
U.S, $32.95 Con. $45.95 
CD-ROM) 







TO ORDER TOLL FREE CALL 1-800-368-9369 


TELEPHONE 415-924-2575 © FAX 415-924-2576 


OR SEND ORDER FORM 10: WATE GROUP PRESS, 200 TAMAL PLAZA CORTE MADERA, CA 94925 


Book 

Block Art of Windows 

Gome Programming 

Creole Sereograms on Your Pt 
Foto! Distractions 
Flights of Foninsy 

Modeling the Dream CO 
Paying Ged 

Wolktbroughs ond Flybys CO 


Colt, residents odd 7.25% Sales Tox 


USPS (55 first book,'S1 ench odd'l) 
UPS Teo Day (510/52) 

Conoda (510/54) 

Intemnotions® (530/hoak) 

TOTAL 


US/Con Price Total Ship to 


Home 
RR ae 
526 95 S045 
526 95/3095 
504 95/4895 
9g2.95/ 45.95 
52695/37.95 
5295 /45.95 


Company 
Aadress 
City, State, Lip 


Phone 


Payment Method 
CO Chack Enclosed 
Cord 


Mgnolure 


O VISA 


°) MosterCord 


Et p. [hate 
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SATISFACTION GUARANTEED OR YOUR MONEY BACK. 





REED) AECINERILET) Quve les. 


This is a legal agreement between you, the end user and purchaser, and The Waite Group", Inc., 
and the authors of the programs contained in the disk. By opening the sealed disk package, you are 
agreeing to be bound by the terms of this Agreement. If you do not agree with the terms of this 
Agreement, promptly return the unopened disk package and the accompanying items (including 
the related book and other written material) to the place you obtained them for a refund. 


SOFTWARE LICENSE 


Fu 
1) 


The Waite Group, Inc. grants you the right to use one copy of the enclosed software programs 
(the programs) on a single computer system (whether a single CPU, part of a licensed network, 


ora terminal connected to a single CPU). Each concurrent user of the program must have 


exclusive use of the related Waite Group, Inc. written materials. 


The program, including the copyrights in each program, is owned by the respective author and 


the copyright in the entire work is owned by The Waite Group, Inc, and they are therefore pro- 
tected under the copyright laws of the United States and other nations, under international 
treaties, You may make only one copy of the disk containing the programs exclusively for back- 
up or archival purposes, or you may transfer the programs to one hard disk drive, using the 
original for backup or archival purposes. You may make no other copies of the programs, and 
you may make no copies of all or any part of the related Waite Group, Inc. written materials. 


You may not rent or lease the programs, but you may transfer ownership of the programs and 
rélated written materials (including any and all updates and earlier versions) if you keep no 
copies of cither, and if you make sure the transferee agrees to the terms of this license. 


You may not decompile, reverse engineer, disassemble, copy, create a derivative work, or oth- 
erwise use the Programs Except as stated in this Agreement. 


GOVERNING LAW 


This Agreement is governed by the laws of the State of California, 





= 


Po _—EEE EE 





——S SE GEE eee 





LIMITED WARRANTY 

The following warranties shall be effective for 90 days from the date of purchase: li) The Waite Group, 
Inc. warrants the enclosed disk to be free of detects in materials and workmanship under normal use; 
and (ii) The Waite Group, Inc. warrants that the programs, unless modified by the purchaser, will sub- 
stantially perform the functions described in the documentation provided by The Waite Group, Inc. 
when operated on the designated hardware and operating system. The Waite Group, Inc. does not war- 
rant that the programs will meet purchaser's requirements or that operation of a program will be unin- 
terrupted or error-free. The program warranty docs not cover any program that has been altered of 
changed in any way by anyone other than The Waite Group, Inc. The Waite Group, Inc. is not respon- 
sible for problems caused by changes in the operating characteristics of computer hardware or computer 
operating systems that are made after the release of the programs, nor for problems in the interaction 


of the programs with each other or other sotrware. 


THESE WARRANTIES ARE EXCLUSIVE AND IN LIEU OF ALL OTHER WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE OR OF ANY OTHER 
WARRANTY, WHETDHER EXPRESS OR IMPLIED. 


EXCLUSIVE REMEDY 


The Waite Group, Inc, will replace any defective disk without charge if the detective disk is returned 
to The Waite Group, Ine. within 90 clays from date of purchase. 

This is Purchaser's sole and exclusive remedy for any breach of warranty or claim for contract, tort, 
or damages. 


LIMITATION OF LIABILITY 


THE WAITE GROUP, INC. AND THE AUTHORS OF THE PROGRAMS SHALL NOT IN 
ANY CASE BE LIABLE FOR SPECIAL, INCIDENTAL, CONSEQUENTIAL, INDIRECT, OR 
OTHER SIMILAR DAMAGES ARISING FROM ANY BREACH OF THESE WARRANTIES 
EVEN IF THE WAITE GROUP, INC. OR ITS AGENT HAS BEEN ADVISED OF THE POS- 
SIBILITY OF SUCH DAMAGES. 

THE LIABILITY FOR DAMAGES OF THE WAITE GROUP, INC. AND THE AUTHORS 
OF THE PROGRAMS UNDER THIS AGREEMENT SHALL IN NO EVENT EXCEED THE 
PURCHASE PRICE PAID. 


COMPLETE AGREEMENT 


This Agreement Constitutes the complete Apreement berween The Wa ite G POL Inc. anc the authors 
of the programs, and you, the purchaser. 

Some states do not allow the exclusion or limitation of implied warranties or liability for inciden- 
tal Or consequential damages, bi the above exclusions cr limitations Tay Fit apply fan VOL, Th Ls lum- 


ited warranty gives you specific legal rights; you may have others, which vary from state to state. 
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SATISFACTION REPORT CARD 


rank eens mien 





Company Name: 





Division/Department: 


Mail Stop: 
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Lost Nome: First Nome: Middle Initial: 
Street Addresst —_ 
Citys Stote: a Zip: 
Daytime telephone: | " 
Dote product wos acquired: Month Doy Year Your Occupation: iS 
Overall, how would you rate Gardens of Imagination? Where did you buy this book? 
C] Excellent LJ) Very Good LI] Good —] Bookstore (name! 
| Par —| Below Average LI Poor C1 Discount store (name: 
What did you like MOST about this book? | ~) Computer store (name): 
C) Catalog (name zy. 
L) Direct from WGP | Other 


What did you like LEAST about this book? 


Please describe ony problems you moy hove encountered with 
installing or using the disk: 


How did you use this book (problem-solver, tutorial, reference...)? 





What is your level of computer expertise? 
_| New (J Babbler LC) Hacker 
|. Power User Lo Programmer (©) Expenenced Professional 


What computer languages ore you fomiliar with? 


Please describe your computer hardware: 


Computer Hard disk 
525" disk drives 3,5" disk dives 
Video card _ Monitor 
Printer Peripherals - 
Sound Board CD ROM 


What price did you pay for this book? 


What influenced your purchase of this book? 

Ll Recommendation Advertisement 
_) Magazine review 
CL) Mailing 

| Reputanonof Waite Group Press =) Other 


sone display 


Se 2 pe 


Hook's format 
How mony computer books do you buy each year? 


How mony other Waite Group books do you own? 
What is your favorite Waite Group book? 


Is there any program or subject you would like to see Waite 


Group Press cover in o similar approach? 

Additional comments? 

Please send to:  Woite Group ah 
Atin: Gardens of Imagination 
200 Tamol Ploza 
Corte Madera, CA 94925 


( Check here for o free Waite Group cotalog 
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THE WAITTE GROUP 





wennnadis 3D Maze Games in € Y C++ 


GARBCKS OF 
You've outwitted and outrun the Nazi prison guards Si AG HR AW i @ Mi 





in Wolfenstein 3D and managed to escape mortal — : 
devastation in DOOM. But you couldn't even begin to fathom how the creators of these 
wildly popular computer maze games programmed these spittire-paced, smooth-animated 3D 
masterpieces. Until now—Gardens of Imagination: Programming 3D Maze Games in C/C++ 
blows the lid off the maze game programming mystery. The sequel to Flights of Fantasy, author 
Christopher Lampton’s ground-breaking flight simulator programming guide, this intermediate 
book and accompanying disk give you all the technical know-how needed to write your own 
heart-pounding, spine-tingling. maze games using Borland C++. 


Gardens of Imagination clearly explains the best-kept maze programming secrets used 
in. state-of-the-art games like Wolfenstein 3D. Lampton offers step-by-step instructions for such 
- functions as maze design, texture mapping, and the haoltesk new ray casting techniques. You'll 
see how to cast variable light on inside walls, create stairs and table surfaces, and bitmap floors 


sand ceilings. Plus you'll learn all the essential nuts and bolts, from programming standard input 





devices like the mouse and joystick to generating faster graphics using little-known VGA Mode X. 
Additional features: 
* Includes high-speed maze game and source code 
* Support available from author on CompuServe'GAMERS forum a 
© Design mazes and import graphics easily with the accompanying utility programs 
Operating System: MS- Dos 
Level: Intermediate/Advanced 


Requires: 386 with: o-387 or 486 DX, 4 AB RAM, 


10 MB hard dis é nace, VGA (or SVGA) graphics board, 












Mouse, Borland’ 3.1 or better 
Fs WAITE GROUP PRESS™ e240) | ly i 
, 200 Tomal Ploza == $34.95 USA = 
Corte Madero, CA 94925 +f $48 95 Caonoda | | 





